RFC: Clarify trace lifecycle and git rewrite semantics

[jonathansantilli]

Trace emission timing and history-rewrite behavior are currently implementation-defined, which makes consumer behavior diverge.

Problem

Without shared guidance, producers and consumers interpret lifecycle and revision anchoring differently.

Proposal

Add documentation clarifying:

1. Provisional traces: workspace-time, may omit vcs.
2. Final traces: revision-anchored, should include vcs.
3. vcs.revision should be interpreted as snapshot semantics.
4. For rebase/amend/squash/cherry-pick, producers should either re-emit for new revisions or document their mapping strategy.

Why This Should Be Added

1. Reduces interoperability ambiguity without over-constraining implementations.
2. Improves consistency in downstream attribution queries.
3. Keeps the spec minimal by clarifying interpretation rather than mandating infrastructure.

Compatibility

Documentation-only clarification; no schema break.

Scope

This clarifies interpretation of revision-anchored attribution. It does not define a universal rewrite-mapping protocol.