Live runner: refuse compiled strategies a close-only stream cannot honour (capability receipt v1) - #332

Summary

The native live runner can now prove, before it binds a ledger, that a compiled strategy library is eligible for its close-only stream. It refuses by name any library whose declarations that stream cannot honour. Before this change, a library that needed intrabar calculation or other non-close-only behaviour could run close-only and silently compute a different strategy.

• Additive capability extension v1, per strategy, discovered with dlsym, like the checked-settings extension:
  • strategy_capabilities_api_version() returns 1;
  • strategy_capabilities_receipt(...) returns canonical JSON through the checked-settings buffer protocol;
  • the receipt lists the compiled execution declarations, the requested series and sites, the runtime requirements, and anything the analysis could not resolve;
  • the bytes are immutable across fresh and reused handles;
  • PF_ABI_VERSION, the kernel and every batch path are unchanged.
• Runner admission policy. It admits only what an equivalence test proves and refuses everything else by name, before any ledger exists. Refused:
  • calc_on_every_tick, calc_on_order_fills, calc_on_every_history_tick, process_orders_on_close and use_bar_magnifier when true;
  • non-default fill assumptions;
  • every request.*, including request sites whose data is not pinned;
  • auxiliary or native security feeds, FX curves and recorded series;
  • the bar-state builtins whose meaning differs between history and realtime: barstate.islast, barstate.islastconfirmedhistory, last_bar_index, last_bar_time, barstate.isrealtime, timenow. This includes display-only use;
  • any declaration the analysis could not resolve to a literal.
    The receipt is bound into the deployment identity, so a changed receipt on resume is refused. A legacy library without the extension warns and runs, under the same policy as checked settings.
• Docs. docs/strategy-capabilities.md and runner/README.md say exactly what is refused and why, with a link to "Backtest vs live". Refusing requests and POOC is deliberately conservative; shapes that the stream equivalence tests prove can be admitted in a later change.

Verification

• Runner end-to-end tests driven by codegen-emitted libraries, one per refused declaration and per admitted class: each refusal happens before the ledger exists.
• A batch-vs-stream equivalence test for every admitted class.
• A test that a changed receipt alone moves the deployment identity, and that the routing wrap is applied last.
• A check that the generated fixtures still match fresh codegen output.
• Corpus parity 312/312, 0 moved.
• Engine bundles (pineforge/verify) and a coordinated parity sweep with the paired codegen change (pineforge/parity).
• Three independent reviews: BLOCK, then fixes; MERGE-WITH-FIXES, then fixes; then MERGE.

🤖 Generated with Claude Code