fix(blackbox): show live durable sync progress

[lupuszr]

Summary

Fix Blackbox dashboard sync reporting so it follows the durable parent snapshot across retries, fallback catch-up, and bounded exact-repair work.

The dashboard now:

• displays the live current / expected durable checkpoint while DKG fallback catch-up is running
• keeps progress visible when an older source-pinned request has exited or failed
• preserves progress across running and waiting transitions
• prevents same-manifest retries from moving the progress bar backward
• prevents small exact-repair submanifests from masquerading as a completed parent snapshot
• reports Blackbox health as updating while verified graph recovery is active

User-visible problem

The node could be receiving and checkpointing millions of graph triples while the dashboard continued to show only the cached verified-threat count. During exact recovery, the panel could also switch from the multi-million-triple parent snapshot to a small bounded window such as 11,000 / 11,000 and incorrectly render Finalizing verified snapshot.

Observed symptoms included:

• verified-threat count appeared static even though daemon checkpoints advanced
• an older failed source-pinned request covered a newer live DKG fallback job
• retry windows made displayed progress regress
• exact VM repair windows appeared as false 100% snapshot completion

The verified cache remained usable throughout; this PR fixes the monitoring/state-composition layer rather than changing DKG transport or storage behavior.

Root causes

1. graph-status merged durable log progress only when the source-pinned Blackbox transfer had status=running.
2. DKG can continue through a replacement/native catch-up job after that source-pinned HTTP request exits.
3. Same-manifest retry windows could return a smaller local offset than the persisted safe checkpoint.
4. Exact VM recovery emits a nested rootless manifest for the same Context Graph. The parser treated every 0 -> positive window as a replacement snapshot, even when the entire child window was already behind the incomplete parent prefix.
5. waiting state writes did not retain all durable progress fields.

Sequence: failure before this change

sequenceDiagram
    participant CLI as Blackbox source-pinned sync
    participant DKG as Managed DKG daemon
    participant State as Blackbox sync state
    participant UI as Dashboard

    CLI->>DKG: Start curator-pinned catch-up
    DKG-->>CLI: Transport closes or request deadline fires
    CLI->>State: Persist failed source-pinned result
    Note over DKG: Native durable catch-up keeps running
    DKG->>DKG: Advance safe checkpoint
    UI->>State: Read old failed result
    UI-->>UI: Show stale cached count or failure

Loading

Sequence: live progress composition after this change

sequenceDiagram
    participant UI as Blackbox dashboard
    participant State as Blackbox sync state
    participant DKG as DKG catch-up status
    participant Log as Durable progress log
    participant Merge as Activity-state merger

    UI->>State: Read persisted source-pinned result
    UI->>DKG: Read current fallback catch-up job
    UI->>Log: Read parent snapshot checkpoint
    UI->>Merge: Compose authoritative, catch-up, and durable state

    alt source-pinned request is running
        Merge->>Merge: Merge durable checkpoint monotonically
    else fallback DKG catch-up is running
        Merge->>Merge: Preserve diagnostic failure separately
        Merge->>Merge: Render replacement job as active
    end

    Merge-->>UI: current, expected, percent, updating health

Loading

The persisted authoritative result is not rewritten for presentation. It remains available under sync_progress.authoritative; only the activity view is synthesized from the newer live job.

Sequence: parent snapshot versus nested exact repair

sequenceDiagram
    participant DKG as DKG durable sync
    participant Log as daemon.log
    participant Reader as Durable progress reader
    participant UI as Dashboard

    DKG->>Log: Parent checkpoint 169,332 / 6,357,721
    DKG->>Log: Exact repair 11,000 / 11,000
    Reader->>Reader: Compare child expected with parent received prefix

    alt child fits entirely behind incomplete parent prefix
        Reader->>Reader: Keep parent snapshot active
        Reader-->>UI: 169,332 / 6,357,721
    else manifest is a genuine replacement
        Reader->>Reader: Start the new progress window
        Reader-->>UI: New current / expected
    end

Loading

Behavioral invariants

• Verified queryable threats remain available while a replacement snapshot is being recovered.
• Progress for the same manifest is monotonic.
• A nested repair cannot turn an incomplete parent into a false 100% result.
• A genuinely different parent manifest can still replace the previous progress window.
• Terminal source-pinned evidence remains visible for diagnostics.
• No additional DKG writes, subscriptions, retries, or network requests are introduced by the UI merge.

Implementation

• dashboard/server.py
  • composes a separate activity transfer from persisted state, live DKG status, and durable progress
  • preserves the authoritative diagnostic result
  • renders retryable capacity waits with checkpoint information
  • feeds the composed live state into dashboard health
• dkg_progress.py
  • retains the incomplete parent when a smaller exact-repair window fits behind the received prefix
  • preserves reset behavior for genuinely new snapshots
• sync_state.py
  • preserves public and durable progress fields across active running / waiting transitions
• regression tests cover fallback catch-up, monotonic retries, waiting-state preservation, and nested repair manifests

Validation

pytest -q tests/test_blackbox_dashboard_chat.py tests/plugins/test_blackbox_dashboard_server.py
72 passed, 5 skipped

Live verification on the Blackbox-owned node:

• parent snapshot displayed as 225,184 / 6,357,721, then 385,826 / 6,357,721
• dashboard percentage advanced from 3.5% to 6.1%
• verified cached threats remained queryable and continued increasing
• bounded 11,000 / 11,000 exact repair no longer replaced the parent progress bar

Scope and review focus

This PR changes five Blackbox dashboard/progress files only. It does not change DKG runtime code, node configuration, sync concurrency, installers, storage, or transport timeouts.

Suggested review focus:

1. whether the parent-versus-child manifest selection preserves all legitimate reset cases
2. whether keeping the persisted authoritative failure separate from the synthesized activity view is the right API contract
3. whether running / waiting progress preservation covers every active transition without retaining terminal state accidentally