Follow-up (PR #2356): targeted demand-driven reconciliation (jobId hints, executor proof hints, bounded proof-read concurrency)

[Jurij89]

Roadmap follow-up to PR #2356, from @branarakic (#2356 (comment)): make demanded reconciliation TARGETED instead of inventory-driven.

1. jobId demand hints: carry jobId as a non-authoritative hint with the poke, coalesced in a bounded set; a demanded pass re-reads only the hinted jobs under the existing transition lock. The idle full sweep remains the crash-recovery safety net.
2. Executor receipt as proof hint: the detached executor hands its settled receipt/result to the single-writer reconciler as a hint. The hint never writes queue truth and never authorizes wallet release by itself — the reconciler validates the persisted tx hash and canonical chain proof before acting.
3. Bounded chain-proof concurrency: once targeted, allow small bounded concurrency for chain-proof reads across different wallets while keeping VM/store finalization tightly bounded (mainnet campaigns showed transient store-scheduler saturation — unlimited concurrency trades one bottleneck for another).

Live-gate metrics (also adopted as the PR #2356 canary): user-visible wall-clock KA/sec, inclusion-to-wallet-release p50/p95, same-wallet spacing, control-plane/Oxigraph query count + latency, store queue pressure, zero duplicate nonces/publications.

Prerequisite context: PR #2356 already gives every pass a single partitioned inventory and an atomic { reconciled, pendingWork } outcome, so the hint set slots into runReconciliationPass as a candidate-selection narrowing.