feat(control-plane): report tenant containers to the central Sentry DSN (#7876)

[jeffrey701]

Summary

Wires the hosted fleet's tenant containers to report to the central Sentry DSN (#7876, implements #4934), reusing src/selfhost/sentry.ts's existing opt-in init rather than building a second Sentry-wiring mechanism.

A tenant container runs an unmodified self-host image (root Dockerfile for ORB, packages/loopover-miner/Dockerfile for AMS), whose process already inits error reporting from SENTRY_DSN via src/selfhost/sentry.ts → src/server.ts:336's initSentry(process.env) (a complete no-op when unset). So pointing the fleet at the central DSN is purely injecting that value at container cold boot — the exact seam LOOPOVER_PINNED_VERSION (#4898) and LOOPOVER_TENANT_SECRET_TOKEN (#8202) already use.

• container-driver.ts: new SENTRY_DSN_ENV_VAR + optional centralSentryDsn on ContainerDriverConfig; createTenantContainer injects it into the container's start() envVars alongside the existing pinned-version / bootstrap-secret vars. Absent/blank ⇒ omitted, byte-identical to the pre-Wire hosted control-plane + tenant containers to report to the central PostHog project (implements #4934) #7876 start() call.
• driver-factory.ts + worker.ts: thread the central DSN from the control-plane's own env.SENTRY_DSN (a secret provisioned by Provision a loopover-owned Posthog project for the hosted fleet #7875) into the container driver. Unset ⇒ nothing injected.
• env.d.ts: declares SENTRY_DSN as the control-plane secret (kept a secret, never a committed var).

Self-host is completely unaffected: src/selfhost/sentry.ts is untouched; an operator who sets their own SENTRY_DSN behaves exactly as before. This only supplies a value the hosted platform would otherwise leave unset, and only at the hosted provisioning path.

Scope note

This covers the tenant-container half end-to-end (where the fleet's actual review/compute error volume lives). The control-plane Worker's own SDK reporting is a deliberate follow-up: it needs a Worker-runtime Sentry SDK (@sentry/hono, as the main app uses), but control-plane/ is a non-workspace package with its own isolated npm ci, and adding @sentry/hono there hits an unresolvable @cloudflare/workers-types v4-vs-v5 peer conflict that would break that install — so it is intentionally not forced into this PR.

Validation

• control-plane build + full test:node (206 tests) green; 100% line + branch coverage on both changed source files (container-driver.ts, driver-factory.ts), verified against the real control-plane:coverage lcov harness — the package stays at its established 99.5%+ with these additive tests.
• cf:typecheck (worker tsconfig, covers env.d.ts + worker.ts) and the root npm run typecheck are green; the full changed-graph test:changed net passes.
• New tests pin: a container starts with SENTRY_DSN when the config carries the central DSN; it merges with pinned-version + bootstrap-secret into one start(); a blank/unset DSN injects nothing (byte-identical); and the factory threads env.SENTRY_DSN (and omits it for ""/" "/unset).

Closes #7876

[superagent-security]

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.63%. Comparing base (264f26a) to head (0bb32d4).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8269      +/-   ##
==========================================
- Coverage   92.15%   91.63%   -0.53%     
==========================================
  Files         786      786              
  Lines       78860    78884      +24     
  Branches    23801    23800       -1     
==========================================
- Hits        72676    72285     -391     
- Misses       5062     5524     +462     
+ Partials     1122     1075      -47     

Flag	Coverage Δ
control-plane	99.85% <100.00%> (+<0.01%)	⬆️
shard-1	53.35% <ø> (-0.55%)	⬇️
shard-2	49.47% <ø> (-0.76%)	⬇️
shard-3	56.66% <ø> (-0.60%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
control-plane/src/container-driver.ts	100.00% <100.00%> (ø)
control-plane/src/driver-factory.ts	100.00% <100.00%> (ø)
control-plane/src/index.ts	100.00% <100.00%> (ø)

... and 3 files with indirect coverage changes

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-23 21:23:33 UTC}

7 files · no blockers · CI green · clean

⏸️ Suggested Action - Manual Review

• AI review could not be completed: The dual-model AI review did not return a usable verdict for this change.

Review summary
AI review could not be completed for this PR head. LoopOver is holding this PR for manual review instead of relying on deterministic signals alone.

Nits — 1 non-blocking

• AI review could not be completed — The gate is held for a human reviewer rather than passed automatically; it re-evaluates on the next update.

Decision drivers

• ✅ Code review — No blockers (No AI review summary)
• ⚠️ Gate result — Not blocking (Advisory; not blocking this PR.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#7876
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 (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 75 registered-repo PR(s), 40 merged, 16 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jeffrey701; Gittensor profile; 75 PR(s), 16 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: jeffrey701
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Rust, TypeScript, Clojure, JavaScript
• Official Gittensor activity: 75 PR(s), 16 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

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.

🧪 Chat with LoopOver

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

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

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 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 LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[andriypolanski]

Hi, @jeffrey701
#7876 is blocked by maintainer-only labeled issue #7875, how could you submit this pr?

[JSONbored]

Not yet available, blocked as per the development pipeline.