Board #674: token-bound active binding generation projection

B2 integration assertion follow-up
----------------------------------
Tested source: 89825140c3313a1677034e0ec18e632d73e73be7.
Only test678's exact adopted-item expectation adds binding_request_id: requestId;
the assertion remains toContainEqual (not weakened to a partial match).
No product implementation changed in this follow-up.
Docker: tests/test678-daemon-token-owner/Dockerfile, SOURCE_COMMIT as above;
run --init --cpus=2 --network none, no source mount or TEST678_CASES override.
SQLite: 21 pass, 0 fail, 347 assertions; all 11 ownership mutations assertion-red.
PostgreSQL: 21 pass, 0 fail, 347 assertions; all 11 ownership mutations assertion-red.
Combined test678 suite rc=0. SQLite completed before PostgreSQL ran.
This result append is the only post-test change; production was not touched.

Reverification after #678 / Hub .111 (supersedes counts below)
------------------------------------------------------------
Tested source: 2e73b48373cf6f9362652225d6d89e97158920a1.
Merged main 613970decc22069be11c8cc39c6c22fe013c718f with a normal merge,
not a rebase. The only textual conflict was qa.yml: both test674 and test678
path triggers and independent jobs were retained. Product diff against that
main is still only the additive tools.ts projection; no changes to #678's
auth.ts, create-node.ts or server.ts identity checks.

Docs distinguish the owner's utok (denied) from a valid target-daemon node
token held by that owner. Other-daemon isolation is based on the identity
resolved by .111 ownership/exact-binding checks and legacy compatibility,
not a caller-controlled token name. Projection remains a snapshot, not a lease.
New real-HTTP test issues a token explicitly bound to the child, confirms the
parent daemon still sees its active binding, then asserts the child's response
is exactly {ok:true,count:0,children:[]}. Same owner/network is not parent identity.

Docker build with SOURCE_COMMIT above; run --init --cpus=2 --network none.
SQLite: 7 pass, 0 fail, 51 assertions, all 10 independent mutations witnessed red.
PostgreSQL: 7 pass, 0 fail, 51 assertions, all 10 independent mutations witnessed red.
Combined suite rc=0. The new child mutant removes only the daemon predicate,
retaining both SQL placeholders: red in the named empty-list assertion on
both engines, not a bind-count/setup error. All previous 9 mutants also rerun.
Additional mutation in this post-#678 run (not present in the historical table):
name        SQLite     PostgreSQL   assertion that goes red
child       rc=1       rc=1         child token sees an empty list, not parent binding
Identity-layer ownership mutations are test678's responsibility. test674 only
tests projection and its scope, including that it calls the identity resolver;
its resolver-bypass mutant does not prove the resolver's ownership checks.
SQLite adoption/lifecycle/start regression: 22 pass, 93 assertions, rc=0.
Docker registration/coverage/home-path/L1-SHA/mutation-pin gates rc=0;
607 anchors checked, 4 unchanged baseline exceptions.
Both symbol-pin scopes rerun in Docker with read-only historical Git objects:
root 9 checked / 8 skipped; docs-site 16 checked / 2 skipped;
zero missing refs and zero drift. Skips are not passes. Initial history-free
container checks could not resolve 7 refs; those are not the final result.
Full server/PG migration ladder and released-client compatibility replay were
not rerun. This follow-up report is the only post-test change. No production
or real nodes touched. #678 deployment/no-old-Hub-rollback constraints remain
in force; this field-only PR does not relax them.

Original pre-#678 verification (historical)
------------------------------------------
Tested source: fe1b52a53ab0ed75cc6b898926b1c85fd54b3c1b
Base: 28c82c7681b44b8ed4ef3dcc706e442acbe86699

Only active adopted list_my_children items add binding_request_id. The existing
request UUID is the opaque generation. No schema migration, authority widening,
new start action or existing-field change. Created items remain byte-for-field
equivalent. get_adopt_request remains pending-only. Snapshot is not a lease.

Docker build: tests/test674-binding-generation/Dockerfile, SOURCE_COMMIT as above.
Run: --rm --init --cpus=2 --network none. No source mount. SQLite runs first;
any failure stops the ladder before PostgreSQL. PG is a fresh in-container
server with an ordinary password-authenticated role, one database per case.
Hub binds loopback port 0; every case uses its own temporary HOME/database.
Requests, acknowledgements, revocation and reads go through real HTTP/MCP.
Fixture users/nodes/tokens and deliberately inconsistent isolation sentinels
are seeded in the disposable test database, never in a real Hub.

SQLite: 6 pass, 0 fail, 43 assertions; suite rc=0.
PostgreSQL: 6 pass, 0 fail, 43 assertions; suite rc=0.
No PostgreSQL extra-bind or parameter type failures. Both positional values
remain bound in predicate-removal mutants so SQL errors cannot fake a red test.

Independent mutants (each starts a fresh Hub/database and restores its source):
name        SQLite     PostgreSQL   assertion that goes red
projection  rc=1       rc=1         exact adopted generation response
token       rc=1       rc=1         humans/general/revoked/other owner denial
daemon      rc=1       rc=1         same-network wrong daemon sees no children
network     rc=1       rc=1         cross-network binding sentinel excluded
join        rc=1       rc=1         node/binding network mismatch excluded
active      rc=1       rc=1         pending/refused/revoked never authoritative
rotation    rc=1       rc=1         revoked R1 is not reused by new request
revival     rc=1       rc=1         old ack cannot reactivate revoked R1
consumer    rc=1       rc=1         old/missing generation refused by daemon
Every row required the named failing test AND an expect(received) diagnostic;
an environment/import/syntax failure alone does not pass the mutation driver.
Mutation driver and final combined suite rc=0 for both databases.

Related SQLite regression: node-daemon-bindings, node-lifecycle-controllable,
start-node: 22 pass, 0 fail, 93 assertions, Docker rc=0 (product-equivalent
snapshot before adding the extra pending-only HTTP assertion).
Docker static gates: registration, coverage, home paths, L1 SHA, mutation pins
rc=0; 598 anchors checked, 4 unchanged baseline exceptions. Symbol pins root:
9 checked / 8 skipped; docs-site: 16 checked / 2 skipped; no drift/missing refs.
Skips are not passes. No full server-wide suite or PG migration ladder run.

Compatibility: only one additive field, no existing field changes. Source-level
old-consumer projection and created shape tested. Actual released app x new Hub
and .120 daemon x new Hub replay remains an operator pre-deployment gate; NOT
claimed completed here. Existing human lifecycle-read API is not changed.
Later #659 B must re-read authority at action boundaries and honor in-flight
revocation protection. This read is not a startup lease.

Recovery: same Hub service/deploy scripts, ports/proxies and secret sources.
Upgrade/rollback uses the existing exact-main release process; no migration or
data conversion. Existing binding records still require normal DB backups.
No production, real nodes, real tmux, package release or deployment touched.
Post-test changes are documentation only (scope wording plus this report).
