Summary

Closes #5143. Audit follow-up to #3298: the three remaining prompt-cache
determinism soft spots were sustained-by-convention rather than
enforced-by-type. None exploitable today, but each was one careless
change from silently invalidating the Anthropic/OpenAI prompt cache
(~75% input-token savings). Each is now enforced at its boundary with a
determinism regression test mirroring
mcp_summary_is_byte_identical_across_input_orders.

Soft-spots addressed

• serde_json/preserve_order implicitly load-bearing for openai
  request bodies — crates/librefang-llm-drivers/src/drivers/openai.rs
  (non-streaming 1083-1087, streaming 1502-1509). The
  extra_body: HashMap was merged into the wire body via obj.insert,
  byte-stable ONLY because the workspace does not enable
  serde_json/preserve_order (so serde_json::Map is BTreeMap).
  Extracted merge_extra_body() which collects + sorts keys before
  insertion, so the merged body is deterministic regardless of which
  serde_json::Map backend is active. The existing
  test_oai_request_extra_body_merged_overrides_standard_field now
  calls the production helper instead of a hand-copied merge loop.

• HookRegistry::collect_prompt_sections ordering depends on
  registration order — crates/librefang-runtime/src/hooks.rs
  (200-205). BeforePromptBuild handlers feed Section 16 of the
  system prompt; they live in a Vec inside a DashMap, appended in
  registration order. No production handler registers BeforePromptBuild
  today, but a future filesystem/plugin-discovered handler would leak
  its order into the prompt. Now sorts the collected sections by the
  stable (provider, heading) key at the boundary before returning.
  Renamed test_collect_prompt_sections_returns_in_registration_order
  → _returns_sorted_by_provider to match the new contract.

• SkillRegistry::list() returned unsorted (HashMap order) —
  crates/librefang-skills/src/registry.rs (360-362). Prompt-bound
  callers (sorted_enabled_skills, all_tool_definitions) sorted
  downstream, but the bare list() is also called from the API
  (routes/commands.rs:63,102) and CLI (main.rs:7157), and any future
  prompt-side caller picking up .list() directly would silently
  reorder. list() now sorts by manifest.skill.name; the existing
  downstream sorts remain (defense-in-depth; all_tool_definitions
  reads self.skills.values() directly, not via list()).
  Order-insensitive API/CLI consumers are unaffected.

Not changed

• Anthropic / Gemini drivers: confirmed they have NO HashMap-merge-into-
  wire-body pattern (grep for as_object_mut / obj.insert over a
  HashMap returns nothing; only OaiRequest in openai.rs does this).
  Scope is correctly limited to openai.rs.
• deny.toml rule pinning the serde_json feature set: optional per the
  issue. The explicit sort makes the merge correct regardless of the
  feature, which is a stronger guarantee than a lint that only fires if
  someone touches Cargo.toml; a deny.toml rule would be a separate
  tooling-domain change and is not required to close the issue.

Tests (real assertions, byte-equality across two input orders)

• librefang_skills::registry::tests::list_is_deterministic_across_insertion_orders
• drivers::openai::tests::extra_body_merge_is_byte_identical_across_insertion_orders
• hooks::tests::collect_prompt_sections_is_deterministic_across_registration_orders

Verification

• cargo check --lib: librefang-skills, librefang-llm-drivers,
  librefang-runtime, plus downstream librefang-kernel,
  librefang-api, librefang-cli — all clean.
• cargo clippy --all-targets -- -D warnings: skills, llm-drivers,
  runtime — zero warnings.
• cargo test: skills (1 new), llm-drivers (3, incl. 1 new), runtime
  hooks (7, incl. 1 new + 1 renamed), kernel skill regression suite
  (80 passed) — all green.