fix(rees): require auth for /metrics and guard server startup

[JSONbored]

Motivation

• The REES /metrics endpoint was exposed without authentication and could be scraped remotely, revealing aggregate telemetry and analyzer health; the service needs to enforce the same shared-bearer auth used by its private API.
• Tests and imports should be able to import the Hono app without starting a network listener so route-level tests can run in-process.

Description

• The /metrics route now checks normalizeSharedSecret(process.env.REES_SHARED_SECRET) and calls verifyBearer(...) before returning Prometheus text via renderMetrics() so unauthenticated scrapes are rejected.
• Server startup side effects (calling serve() and installing process signal handlers) are wrapped behind a direct-execution guard using if (import.meta.url === pathToFileURL(process.argv[1] ?? "").href) so test imports do not open a listener.
• Added a regression test review-enrichment/test/server-metrics-auth.test.ts that asserts unauthenticated scrapes receive 401 and authenticated scrapes receive metrics, and adjusted imports (pathToFileURL) needed for the startup guard.

Testing

• Ran git diff --check which produced no trailing-whitespace or conflict-marker errors and succeeded.
• Ran the REES test suite via npm run rees:test which completed with all tests passing.
• Ran the new route tests directly with node --test --experimental-strip-types test/server-metrics-auth.test.ts and they passed locally.
• Attempted npm audit --audit-level=moderate but the registry audit endpoint returned 403 in this environment, so the audit could not be completed here.

---

Codex Task

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-12 23:23:14 UTC}

2 files · 2 blockers · readiness 89/100 · CI green · clean

⏸️ Suggested Action - Manual Review

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

📋 Copy for AI agents — paste into your coding agent

Fix the following blocker(s) from this PR review:

1. No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.

2. Maintainer requires a linked issue — Link the relevant issue (for example `Closes #123`) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	No AI review summary
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (draft PR; no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 44 registered-repo PR(s), 36 merged, 424 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 44 PR(s), 424 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 44 PR(s), 424 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Mark ready when done.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[JSONbored]

Closing as a regression, not a fix.

The premise — that REES's GET /metrics is internet-exposed and "could be scraped remotely" — doesn't hold under this repo's actual, deliberate architecture:

• docker-compose.yml's rees service uses expose: ["8080"] with an explicit comment: "Never published to the host — reached only over the internal docker network at http://rees:8080, same in-network-only posture as postgres/redis/qdrant/browserless."
• The Railway deployment path uses private networking — review-enrichment/README.md's own Deploy section states no public domain is required.
• prometheus.yml's rees scrape job has zero bearer-token configuration, consistent with all 11 other scrape jobs in that file.
• The main app's own GET /metrics (src/server.ts:829) is likewise unauthenticated, by the same deliberate convention.

More concretely, this would break already-shipped, same-day work: #5412 (aec16727a, already an ancestor of this branch) wired a live Prometheus scrape + a dedicated Grafana dashboard against this exact unauthenticated endpoint, and its commit message documents it was verified end-to-end against a real deployment ("exporter -> scrape -> query"). Merging this PR's 401 gate would silently break that dashboard's data on any correctly configured --profile rees --profile observability self-host install, since Prometheus has no bearer-token wiring to satisfy it.

The code itself is clean and well-tested (the import.meta.url main-module guard is a reasonable pattern) — the underlying premise just doesn't match this repo's actual deployment model. No action needed; flagging for visibility.