Engineering Loop should use a dedicated OpenRouter key, not the NOC Agent key

[Svaag]

The Engineering Loop on loop authenticates to OpenRouter with the "NOC Agent" key (its openrouter_api_key in Vault kv/engineering-loop is the NOC key). Observed during the launch-proof dogfood: the loop's runs 402'd on the NOC Agent key's daily limit, and raising the NOC key's quota unblocked the loop.

Why it matters

• Quota contention: loop runs (multi-minute, high-token coding passes) and the noc-agent investigation traffic share one daily spend cap; either can starve the other.
• Accounting: per-component cost attribution (the token-capital goal) is impossible when both draw on one key. Compounds the cost-visibility gap in Separate servers Edge Router from Firewall #6 / fix(noc): surface OpenRouter quota in model health check #220.
• Blast radius: a runaway in one component exhausts the other's budget.

Ask

1. Provision a dedicated "Engineering Loop" OpenRouter key with its own daily limit.
2. Put it in Vault kv/engineering-loop as openrouter_api_key (replacing the NOC key there); leave the NOC Agent key to kv/noc-agent.
3. (With fix(noc): surface OpenRouter quota in model health check #220) surface each key's remaining daily headroom in model-health so exhaustion is caught before runs 402.

Acceptance

• loop and noc use distinct OpenRouter keys; a loop run cannot consume noc-agent's daily budget (and vice versa).

[hyrule-engineering-loop]

Reliability Governor Decision

• role: staff_sre_autonomous_operations
• decision: knowledge_gap
• next_loop: knowledge
• handoff_contract: knowledge_context_pack
• source: human
• intent: secret / tier 4
• capability: none
• knowledge: missing / unknown
• reasons: Knowledge policy result is deny; Knowledge context returned no included_refs

{
  "affected_assets": [
    "AS215932/network-operations"
  ],
  "affected_customers": [],
  "affected_services": [],
  "allowed_paths": [],
  "authority_text_hash": "5e3e56cc8d21d1a87caa9bff4038ce722e816933fb55dbc66b8ad83c0783f7ec",
  "blast_radius": "credential plane",
  "controlled_loops": [
    "engineering",
    "noc",
    "knowledge"
  ],
  "created_at": "2026-06-30T01:55:28.156140+00:00",
  "denial_reasons": [
    "Knowledge policy result is deny",
    "Knowledge context returned no included_refs"
  ],
  "expected_paths": [
    "secrets/"
  ],
  "forbidden_paths": [],
  "governor_name": "Reliability Governor",
  "governor_role": "staff_sre_autonomous_operations",
  "handoff_contract": "knowledge_context_pack",
  "intent_type": "secret",
  "issue_id": "AS215932/network-operations#249",
  "issue_number": 249,
  "issue_text_hash": "dbdb36cfd95ae5b7597d1225b7344adfa9da3b0e11dd0a412fc7bd1badbc2ce0",
  "knowledge_authority_level": "unknown",
  "knowledge_context_pack_id": "ctx_640978e25d8b1fac5060dd68850a6dca",
  "knowledge_export_version": "local-20260623120725",
  "knowledge_status": "missing",
  "labels_to_add": [
    "loop:knowledge-gap"
  ],
  "labels_to_remove": [
    "loop:intake",
    "loop:candidate",
    "loop:approved",
    "loop:needs-context",
    "loop:needs-human"
  ],
  "lhp": null,
  "matched_capability": null,
  "next_loop": "knowledge",
  "policy_rules": [
    "deny stale, contradictory, missing, or errored Knowledge context"
  ],
  "record_id": "662b5110ad5f9a2fa5a8",
  "repo": "AS215932/network-operations",
  "required_checks": [],
  "risk_tier": 4,
  "rollback_plan": "",
  "routing_decision": "knowledge_gap",
  "schema_version": "reliability-governor.cdr.v1",
  "source": "human",
  "storage_path": "/var/lib/engineering-loop/reliability-governor/as215932-network-operations-249-662b5110ad5f9a2fa5a8.json",
  "verification_method": ""
}