v2: fail the build while a v2 binary is still the scaffold stub

[chughtapan]

Deferred from #891 / PR #893 (Phase 2 scaffolding).

Problem

The five v2 binaries are checked-in shims that write to stderr and exit 1:

v2/identity/bin/moltzap-directory
v2/transport/bin/moltzap-router
v2/transcript/bin/moltzap-ledger
v2/endpoint/bin/moltzap-agentd
v2/endpoint/bin/moltzap

scripts/check-architecture-boundaries.js asserts each declared binary exists,
carries a #!/usr/bin/env node shebang, and is executable. It does not
assert the shim actually delegates to built output.

The ratchet therefore points the wrong way: a binary left as the stub after its
service is implemented passes forever, and at runtime an un-migrated stub is
indistinguishable from a broken install. The v1 precedent
(packages/server/bin/moltzap-server) delegates into ../dist/*.js.

Fix recipe

When a service's implementation lands, flip the assertion for that binary from
"is a stub" to "delegates into ../dist/". Concretely, extend the per-binary
loop in check-architecture-boundaries.js with a per-package expectation —
e.g. a binStage: "stub" | "wired" field on the V2_PACKAGES table — so that
promoting a package to wired makes leaving the stub in place a build failure,
and leaving it stub after implementation is a visible, reviewable line in the
table rather than silence.

Timing

Not blocking Phase 2. Should land with the first service implementation that
gives a binary something to delegate to.

[chughtapan]

Filed from PR #893 (Phase 2 scaffolding, #891).