fix(transcript): keep derived history record identities unique

[aron-intframe]

Summary

stampHistoryRows derives its last-resort record address as m:<messageID>:notice:<i>. Interrupted-attempt records are persisted without a message id, so two of them both derive m::notice:0, NewProjection rejects the whole baseline, and the session cannot be opened at all — including after a restart.

Disambiguated with a used set, the way the sibling repairCheckpointRecordIdentities already does. Canonical m:/tool: addresses are untouched, so genuine duplicates are still rejected.

Issues

Refs #10456 — I could not reproduce that report's exact identity (tool:call_00_…), only the derived m::notice:N collision, so Refs rather than Fixes.

Verification

go test ./internal/transcript/ green; gofmt -l and go vet clean. Two new tests, both built from the production constructor agent.InterruptedStreamRecord:

• TestHistoryKeepsDerivedRecordIdentitiesUnique — reverting the fix fails it with rows 1 and 3 share record identity "m::notice:0".
• TestHistoryKeepsCanonicalDuplicatesRejected — inverse guard; tool:reused-call twice must still fail.

Linux, root module only. Two failures elsewhere (control TestServeForkStartsNoBroaderThanInheritedReadOnly, agent TestRepairSessionListingProjectionHealsRecoveryLedgerOnce) also fail on a clean main-v2 with this change stashed.

Documentation impact

Documentation-impact: none - no user-visible behavior change.

Cache impact

Cache-impact: none - display projection only.
Cache-guard: n/a; internal/transcript records never enter provider messages.
System-prompt-review: N/A

[github-actions]

Thanks, this is a clean fix. I merged it onto current main-v2: the transcript tests pass, reverting the production change fails the new test with the shared m::notice:0 identity you describe, and the inverse test keeping real duplicate canonical identities rejected is the right guard. One small nit: the doc comment on stampHistoryRows is longer than our 5-line declaration limit; keeping just the constraint (only the derived address is disambiguated, canonical addresses still fail the projection) is enough. Otherwise this is good to merge.