🔒 feat(security): harden production trust boundaries

[cookesan]

Summary

This establishes a production-readiness baseline across outbound networking, review automation, billing, scheduled maintenance, storage migration, supply-chain controls, and operator documentation.

• Introduces a shared outbound HTTP client with scheme and userinfo validation, public-destination policy, redirect revalidation, cross-origin credential stripping, downgrade blocking, byte-stable replay, response caps, and interruption-aware cancellation.
• Migrates every credential-bearing outbound surface to the shared policy, including generic HTTP and OpenAPI tools, search, document parsing, transcription, integrations, diagnostics, and review inference.
• Rebuilds pull-request review as three trust domains: base-controlled policy and analysis, isolated untrusted-head execution, and a schema-validating publisher. Identity, head/base revisions, artifacts, quotas, environment, and publish authority are bound independently.
• Adds atomic billing reservations with expiring leases, transactional settlement, conservative ambiguous-response charging, strict priced-model selection, and safe fallback rates.
• Makes scheduled maintenance deterministic and credentialless until an isolated publisher verifies a bounded, hashed, repository-bound manifest.
• Pins every executable external Action to a full commit, adds static analysis and dependency review, enforces a production dependency audit with time-bounded upstream exceptions, and documents the threat model, disclosure process, hardening controls, and operating runbooks.
• Completes the seeded monitoring workflow pack and documentation, makes example-graph tests process-hermetic, bounds automatic post-failure investigations, closes launcher descriptors, and prevents detached test subprocess leaks.
• Rejects structurally malformed SQLite WAL/SHM sidecars before native open, preserving files and returning actionable migration errors instead of risking a process crash.

Trust guarantees

• Redirects never silently carry secrets to an unauthorized origin or downgrade HTTPS.
• Untrusted pull-request code never receives publish credentials, repository write authority, identity tokens, or unrestricted host access.
• Review publication accepts only bounded artifacts tied to the expected repository, workflow, run attempt, head revision, and base revision.
• Billing capacity is reserved before dispatch and settled atomically, preventing concurrent requests from overspending one allowance.
• Scheduled analysis cannot publish directly and cannot consume long-lived credentials.
• Workflow automation is bounded: polling, backoff, retries, request bodies, response bodies, artifacts, and generated changes all have explicit limits.

Validation

• pnpm verify
• Offline frozen-lockfile install
• 48 YAML files parsed successfully
• 56 executable external Action references use exact 40-character commit pins; 2 repository-local references remain local
• Production dependency audit passes with exactly four unpatched, time-bounded upstream exceptions
• Focused adversarial coverage for redirects, secret stripping, cancellation, response limits, review identity/artifacts, billing reservations, maintenance publication, malformed SQLite sidecars, and detached-process cleanup

Final audit

• Final head: 46d326b3139962fa3128bc864868951424414b9d
• Full local pnpm verify: 1,590 CLI tests passed, 11 environment-gated skips, 0 failures, with every audit, lint, typecheck, documentation, contract, package, UI, engine, and server gate passing.
• Timing-regression stress: 10 repeated editor-failure runs and 20 full SOTA artifact-suite reruns passed with 0 failures.
• Hosted verification: all 14 final-head checks succeeded across Ubuntu, Windows, PostgreSQL, coverage, CodeQL, dependency audit/review, and fault injection.
• Review audit: all 19 security review threads are resolved, with no unresolved conversations.

Repository-admin follow-up

These settings cannot be enforced by the pull request itself:

• Enable Private Vulnerability Reporting. It is currently disabled.
• Require CI, static analysis, and dependency review through a ruleset or protected branch.
• Enable or verify the dependency graph, automated security updates, secret scanning, and push protection where the repository plan supports them.

This is a technical and operational diligence baseline. It materially reduces production and review risk, but it does not by itself guarantee financing or replace product, market, legal, financial, and organizational diligence.

Closes #911
Closes #912
Closes #913
Closes #914
Closes #915
Closes #916
Closes #917
Closes #918
Closes #919
Closes #920
Closes #921
Closes #922
Closes #923
Closes #924
Closes #925
Closes #926
Closes #927
Closes #928
Closes #929
Closes #930
Closes #931
Closes #932

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[roninjin10]

We have 500 commits merging today so this will get massively merge conflicted. Apologies

[roninjin10]

This is too big of a pr to review could you break it up into smaller changes maybe?

[cookesan]

Sure, I'll keep working on it.