Prevent VibeScript History finalization stalls and unify operation status

[10-X-eng]

Problem

A representative 559-output VibeScript Assembly publication completed its isolated solve but left the interface apparently frozen at output 558/559. The owner-thread History finalizer repeatedly performed linear document-membership scans and repeated dependency-graph traversals. Long document and context operations also reported through separate status paths, allowing stale or misleading activity to outlive the document that started it.

Required outcome

• Keep required stale-object and History-order validation while removing redundant whole-document and per-operation scans.
• Paint a truthful History-finalization phase before entering the atomic owner-thread commit.
• Use one thread-safe, Qt-free activity registry and one status-bar adapter for Native jobs, assistant work, Analyze/Drawing context preparation, and document open/save/recompute.
• Reject stale results by persistent document UID and process-local incarnation.
• Preserve public APIs, undo/redo, save/reopen behavior, rollback, and document integrity.
• Prove the changes with representative native performance regressions, Python lifecycle/concurrency tests, independent review, a complete Windows Rattler build, official portable smoke tests, and packaged interactive replay.

Acceptance

• Indexed document membership and shared History traversal remain below the controlled direct-handler budget at representative scale.
• Forward dependencies and cycles retain correct failure semantics.
• Status transitions are balanced on success, failure, observer exception, and unwind.
• Replacement/reopened documents cannot receive stale context work.
• A verified portable package remains responsive and shows the History phase during the representative publication.

The broader application-wide performance program and evidence ledger remain in PERFORMANCE.md; this issue covers the current finalizer/activity checkpoint only.