fix(headless): Harbor can archive a tool result under an id the ref grammar rejects #2036

Harbor's archive writer and the runtime ref grammar disagree on what an artifact id may look like. A tool result can be archived successfully and still be unreadable, because the maka://archive/... ref built from its id fails to parse before it ever reaches the host reader.

The mismatch

harborCellToolResultArchiveArtifactId (harbor-cell-context-budget-env.ts:853) joins three sanitized segments, so the id it produces can reach 217 characters, and can carry = when the session or runtime event id does.

Reproduction

Archiving with either a session id containing = or a 96-character session id yields an id that parseToolResultArchiveResourceRef returns null for:

session=1--event=1--<sha16>.json    length=41    parsed=null
ssss…(96)--eeee…(96)--<sha16>.json  length=217   parsed=null

Failure mode

The archive file is written, the placeholder is emitted, and the model is told to call ArchiveRead. The call then fails with invalid_ref before the Harbor reader is consulted. Nothing in the archive is actually wrong, which makes this read as a broken archive rather than an incompatible name.

The default path does not hit this: session and runtime event ids are UUIDs, so the id lands around 95 characters of hex and -. It is reachable through a programmatic run that injects newId, or any harness that treats those ids as genuinely opaque strings.

Fix direction

Generate ids that satisfy the runtime grammar at the writer, since the runtime parser is the cross-host protocol authority and should not be widened for one host's naming. Drop =, and bound the total length by appending a short hash of the full id rather than truncating segments, so two distinct long ids cannot collide after truncation. Add a round-trip test asserting every id the writer produces parses back, covering = and over-length ids.

Found while cross-reviewing #2028; out of scope there because the writer predates that change.