fix(reliability): apply the relay-field policy to the packaged driver too

[georgi]

Ring 2 has never passed. It was added on 2026-07-30 (0f68fe6, #4606) — after that day's last green release run — and every release since has failed on all three OS legs with streamShape golden mismatch (11); diverges from kernel. Five nightlies plus v0.7.0-rc.33.

Nothing was wrong with the packaged backend.

ws-server.ts already had stripRelayOnlyFields: the WS relay backfills run identity onto frames the kernel actor emits bare, so the driver cancels that enrichment before recording and the two surfaces stay comparable frame-for-frame. packages/protocol/src/messages.ts specifies this — job_id is "Stamped downstream by the relay ... not by the kernel actor", and generation_complete is emitted by the actor as "a BARE event" with job_id and index "stamped DOWNSTREAM by the relay".

packaged.ts is the same kind of relay and never got the rule. It recorded raw frames, so Ring 2 diffed a relay stream against a bare oracle and failed on exactly the fields the protocol says only the relay carries.

A rule that only one of two relay surfaces applies is not a policy, it is a discrepancy — so the sets move to relay-fields.ts and both drivers import them. The packaged driver also drops sdk_execution_target, sent once per socket at upgrade time by the production Fastify plugin before any workflow exists, so the oracle has nothing to compare it against.

Proof

Same commit (1de83a616), same job, same runners:

	packaged verdict
rc.33, run 30927453380	✗ packaged — streamShape golden mismatch (11) — diverges from kernel
this branch, run 30946856111	✓ packaged: completed — verdict: OK

Ring 1 goes from 5 failing journeys to 4. The one that changed is the packaged journey; ws-server's own linear-text-pipeline still passes, so moving the sets regressed nothing.

The four remaining Ring 1 failures are pre-existing and untouched here: mid-run-cancel-node, mid-run-cancel-streaming, provider-failure-mid-stream (Database not initialized), ws-transport-faults.

Deliberately not changed

The journey manifest still declares only ["kernel", "ws-server"]. PackagedDriver has no supports(), so listing "packaged" would make a bare nodetool reliability run linear-text-pipeline fail whenever no bundle is staged — compare.ts records an unstaged run as ok: false.

Not verified locally

npm run lint and npm run typecheck were not run — no working node_modules on the machine this was authored on. CI is the first thing to type-check it; the Ring 1 dispatch above did build and run the harness.