Derive dispatch identity server-side — retire the client-built id-segment

[styk-tv]

Client half of the server-derived identity story. As of v1.5.6 (#11) a verified connection publishes governed dispatches on input.kernel.pgCK.id.<sub>.action.<verb>, where the client builds the id.<sub> segment by reading sub from its own token. That puts the client in the token path and makes it an identity constructor.

Proposal

The client publishes the plain input.kernel.pgCK.action.<verb> (no id segment); the substrate derives created_by/by: from the verified connection. The client then constructs no identity, needs no sub, and sends only {verb, kernel_urn, payload} — never-assert becomes structural.

Depends on

pgCK deriving the requester from the admitted connection rather than the subject segment (pgCK project task #20; server-derived identity itself already shipped as styk-tv/pgCK#9/#10). Gated on that — until it lands, #11 stays exactly as shipped.

Done-when

• cklib publishes the plain subject; the seal records the real created_by; the event by: is correct.
• No token-claim parsing for subject formation remains in ck-client.js; never-assert is structural.
• Docs updated: SPEC.CK-LIB-JS §2.1, SPEC.CK-OPERATIONS §6.1.

Relates

• Supersedes forward: Publish on the identity-scoped dispatch subject (input.kernel.pgCK.id.<sub>.action.>) so verified dispatch seals real identity #11 (id-scoped dispatch subject, closed v1.5.6) — not a reopen.
• Partner axis: Take cklib out of the token path — tokenProvider / inject-nc; retire login #14 (token path) — together, cklib constructs neither identity nor auth.
• Same server-derived principle as Unified server-derived participant presence — client surface (query + events) #13 (presence).

[styk-tv]

Superseded — recording the state, not closing yet

styk-tv/pgCK#11 now carries a ## RESOLVED — the segment stays; the Ask's premise does not hold section, which rules:

"Decision: the id-scoped subject is kept as the attribution mechanism."
"For CK.Lib.Js: do not retire the id-segment builder. It is load-bearing, and no replacement is planned."

Both halves of this issue are therefore void:

1. "Retire the client-built id-segment" — there is nothing to retire. The segment is permanent by ruling, and no replacement mechanism is planned.
2. "Derive dispatch identity server-side" — already shipped in 1.5.6. ck-client.js builds input.kernel.<K>.id.<sub>.action.<verb> from the connection's own verified claims; the client asserts nothing.

Zero client work.

Not closing unilaterally. pgCK#11 states it "Serves #12", so closing this without acknowledgement would strand that issue's stated consumer. Requesting pgCK confirm, then this closes naming pgCK#11's RESOLVED section.

Board Depends on updated to reflect the supersession rather than an in-force dependency — the previous value read as "waiting for pgCK#11 to land, then proceed", which is now the opposite of true: when pgCK#11 lands, this becomes impossible rather than unblocked.