fix(sidecar): load guest software built with V8-incompatible wasm features; make an executable-less package a loud typed error

[WyvernMonarch]

Two failures, one story

Building a guest tool with the repo's own C toolchain and then running it produced a VM that silently had no working binary.

1. binaryen emitted a module V8 refuses. toolchain/c/scripts/build-grep-upstream.sh ran wasm-opt --all-features, which enables extended-const and other post-MVP proposals in the output; the V8 runtime then rejects the module at instantiation. The build "succeeded", the artifact was unusable.
2. The failure was invisible. A package whose projection ends up with no executables booted anyway, and the first exec failed later with a generic error that pointed nowhere near packaging.

The fix

• The grep build now passes the feature set V8 actually accepts instead of --all-features, so a module that builds is a module that loads.
• package_projection.rs detects a configured package that projects zero executables and raises a typed PackageNoExecutables boot error naming the package, with the ACP surface mapping it to a stable package_no_executables code. The failure now happens at boot, at the right layer, with the package name in the message.

Why it is safe

• The toolchain change only narrows the wasm features requested from wasm-opt; modules that already loaded are unaffected, and one that needed a rejected feature never worked in the first place.
• The new error fires only on a package that has no executables at all — previously an unusable-but-silent state, so nothing that used to work starts failing. Existing packages keep booting unchanged.
• cargo build -p agentos-native-sidecar is clean.

Found while shipping a guest grep for VM-sandboxed workers; the same trap applies to any guest package built by that script.