feat: add external API runtime and request control plane

[bballdavis]

Summary

Adds the opt-in external API runtime for #568 on the persistence foundation now merged by #750. This branch is rebased onto current dev (ef996c10); the diff contains phase two only. The administrator UI remains separate in #809.

• Mandatory external-key authentication, even with AUTH_ENABLED=false, plus scopes, channel grants, media/rating policy, durable quotas, and bounded request/work queues. Legacy download keys cannot authenticate the external namespace.
• Cached catalog and authenticated artwork endpoints; owner request history and session-authenticated management APIs. Channel DTOs expose database IDs separately from YouTube IDs, and configuration reports effective feature availability.
• Idempotent video/channel/deletion requests, serialized approvals, authority rechecks after queue waits, and recovery using durable download job identities. Queue-full retries preserve the accepted request, quota charge, and original channel-grant decision.
• Focused request creation, execution, review, and reconciliation modules, with shared pagination and reconciliation; bounded thumbnail fetches and metadata calls, redirect/path checks, and redacted command logging.
• Missing, disabled, or terminated channel grants return a specific 400 validation response; failed creation/editing rolls back key, policy, and grant changes.
• Versioned Swagger/consumer fixtures, a local contract server, and phase-two documentation with tested commands and generated anchors.

Persistence and query plans

The four migrations from #750 and upstream dependency corrections are preserved. The root lockfile updates only proxy-addr from 2.0.7 to the compatible 2.0.8 security patch for GHSA-jqcg-44mw-7w3h; no global overrides were added. There are no obsolete migration markers, channel uniqueness changes, or channel deduplication.

One runtime migration adds two external_requests indexes justified by the actual service SQL. Catalog request status is batched for the displayed page instead of using repeated correlated history scans. The reproducible local fixture contains 300,000 cached videos, 1,000 channels, 30,000 requests, and 10 grants; MariaDB 10.3 and MySQL 8.0 plans select the new indexes. Equivalent indexes under other names are preserved; rollback removes matching owned definitions only. CI now runs the runtime/database matrix and uploads the query-plan reports.

Validation

• Full backend: 223 suites, 6,044 tests passed; no skipped tests.
• Full frontend: 278 suites, 5,174 tests passed; production client build passed.
• Real MariaDB 10.3.39 and MySQL 8.0.46: 23 integration regressions passed on each, including migration lifecycle, legacy keys, duplicate channels, partial recovery, rollback/reapply, actual model/DTO reads, concurrent submissions/approvals, queued grant revocation, enqueue interruptions, quota rollover, retry handling, and invalid-grant HTTP validation with transactional rollback.
• Representative-data service queries, result equivalence, and EXPLAIN checked on both engines.
• Express trust-subnet regression reproduced against 2.0.7 and corrected by 2.0.8; 61 targeted ingress/authentication tests and the CI audit thresholds passed locally after a clean install.
• ESLint, TypeScript, MSW worker consistency, lockfile integrity, brace-glob behavior, 67 backup/restore Python tests, and the live loopback contract executable passed.
• Clean-clone root/website installs, documentation generator tests, and strict production documentation build passed.

All database and consumer data are synthetic. No real customer data, YouTube downloads, deployment, or merge was used for validation.

Verified final head: 9badb936aaec4a84a7403a9d75f03dd76785c4b7. CI run: all checks passed, including both downloadable database query-plan reports.

[dialmaster]

Holding off on a full review of this until #750 is merged, since it's stacked on that one and carries the same commits. Once 750 is merged, can you rebase this on dev so the diff is just phase two? #809 is stacked on this one in turn, so this needs to go in before that.

[bballdavis]

Holding off on a full review of this until #750 is merged, since it's stacked on that one and carries the same commits. Once 750 is merged, can you rebase this on dev so the diff is just phase two? #809 is stacked on this one in turn, so this needs to go in before that.

That was the plan! I just went ahead and started building out the PR's since i was confusing myself what was going where, but left them as draft. Once we get those first two I'll rebase and submit for review.