fix(tracing/viewer): reconstructed in-flight spans render as red error — use a distinct 'interrupted' state

[anandgupta42]

Found during the v0.8.4 release review (End User + Chaos Gremlin personas). Deferred because it needs a viewer status-model change + design, >30 min.

Problem

Trace.rehydrateFromFile (tracing.ts:590-595) closes any still-open generation span with status: "error" so the boundary is visible after a worker restart / MAX_TRACES eviction. The viewer (viewer.ts:470, 568) renders every status === 'error' span with a red ✘ and counts it in errSpans. Result: re-opening a trace whose session completed fine but was mid-step at a restart shows a red 'error' generation — a false alarm on a debugging/postmortem surface where red means 'look here'.

v0.8.4 reworded the statusMessage to disambiguate restart-from-failure (#895 follow-up), but the span status is still error, so any aggregation/filter that keys on status === 'error' still conflates 'recorder restarted' with 'agent failed'.

Proposal

Introduce a distinct span state for reconstructed-but-incomplete spans (e.g. status: 'interrupted' or a reconstructed: true flag) and render it in the viewer as a neutral/amber 'incomplete (reconstructed)' tag rather than red error — and exclude it from errSpans health counts. Keep the boundary visible without implying failure.

Acceptance

• A generation span closed by rehydrate is visually distinguishable from a real agent/tool error in the waterfall and span detail.
• errSpans / session-health signals do not count reconstructed spans as errors.
• tracing-rehydrate.test.ts updated to assert the new state.

Refs: #895