fix(daemon): productionize core repo operations lane

[Svaag]

Summary

• expands the daemon's default intake scope to the seven core AS215932 repos
• maps GitHub repo names to the production workspace checkout names (network-operations -> hyrule-infra, noc-agent -> hyrule-noc-agent)
• sets low-and-slow operations-lane defaults: docs-only mutation boundary, max 2 runs/day, max $10/day
• teaches repository discovery about engineering-loop, hyrule-infra, and optional network-operations checkouts
• adds a dedicated production model/backend policy used by the loop VM after Pi auth

Safety / rollout

• Still stops at draft PR publication; no auto-merge and no production apply path is added.
• Backend execution still refuses to run on GitHub Actions.
• Root model-policy.yml remains mock-backed for offline tests; production policy lives at configs/loop/model-policy.production.yml and is selected by the loop VM systemd unit.

Validation

• uv run --group dev python -m pytest -q — 158 passed
• uv run --group dev mypy --strict src — passed
• uvx ruff check src tests — passed
• uv run hyrule-engineering-loop models validate --model-policy configs/loop/model-policy.production.yml --json — ok (warnings only for absent local API keys)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7b4f9b8f10

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Make Pi auth visible to the production unit

When this unit selects the production policy, every backend tier resolves to pi, but the backend subprocess gets a scrubbed environment, so provider API-key env vars are not available to Pi and it falls back to its login store. The Pi quickstart documents /login storing API-key auth in ~/.pi/agent/auth.json, while systemd.exec says ProtectHome=yes makes /home, /root, and /run/user inaccessible; in this service context pi --print cannot read the loop user's completed Pi auth, so approved runs will fail at backend startup unless HOME/auth storage is moved under /var/lib/engineering-loop or the unit binds/relaxes home access.

Useful? React with 👍 / 👎.