[1.0] Persist run history in SQLite independently of the dashboard

Artifact history is durable, but the collector's run registry is in memory and the agent-run history endpoint returns a placeholder. Useful run history must also exist in headless operation.

Scope

• Reuse task/run identities and existing run/consumption records to persist agent, timing, outcome, input/output references and protected diagnostics in SQLite.
• Expose bounded authorized list/detail reads for this history and use them instead of the empty run-history endpoint.
• Define retention and historical-coverage behavior without implying that old agent snapshots are execution checkpoints.

Acceptance criteria

• A headless deterministic run and a dashboard-enabled run produce equivalent durable history.
• After a clean restart, successful, failed and confirmed-cancelled records retain their identity and outcome.
• Authorized list/detail pagination returns the correct records; foreign readers cannot access protected diagnostics or referenced payloads.

Boundaries

Crash reconciliation and open intake receipts are a dependent ticket; automatic run restoration and workspace export are deferred.

References

• Follow-up to #271; the earlier delivery remains historical context.
• Implementation dependencies: #433, #432.
• src/flock/api/collector.py
• src/flock/core/store.py
• src/flock/components/server/traces/trace_component.py

Start with src/flock/core/store.py, src/flock/api/collector.py, and src/flock/components/server/traces/trace_component.py, then trace the existing run and consumption records and the placeholder history endpoint. Define the SQLite persistence, retention and authorized bounded list/detail behavior within the stated boundaries. Done means headless and dashboard runs have equivalent durable history, records survive restart, pagination is correct, and protected diagnostics and payloads remain inaccessible to foreign readers.