Refactor runtime and MCP modules to standardize gates

[joyzoursky]

Summary

• Decompose large runtime and MCP modules into focused units for maintainability and clearer ownership.
• Standardize API auth/access guard patterns and typed route response helpers across project/team/test-case routes.
• Add repository guardrails and load-gate checks to prevent regression in auth coverage, runner protocol boundaries, and hotspot growth.
• Align CLI/macOS runner protocol defaults and supporting utilities.
• Refresh maintainer documentation to match the new module structure and telemetry paths.

Changes

• Runtime decomposition:
  • Extract Android/runtime/assertion/execution parser modules from test-runner.ts.
  • Add shared worker loop utilities and update maintenance/browser loops.
• MCP decomposition:
  • Split registry, tools, schemas, auth, response/telemetry, and test-case mutation tooling from server.ts.
• API guard standardization:
  • Add reusable route access modules (team/project/test-case) and typed API route standards.
  • Apply shared guard patterns across team/project/test-case endpoints.
• Quality and verification gates:
  • Add scripts for auth-route coverage, runner-protocol boundary checks, config/i18n guardrails, hotspot LOC, and runner contract centralization.
  • Add load-gate scripts for SSE and runner event ingestion.
• CLI/runner protocol alignment:
  • Centralize protocol defaults and improve runner manager/process supervision seams.
• Documentation:
  • Update CLAUDE.md project map/task routing and maintainer docs for MCP and runtime decomposition paths.

Validation

• Code-level validation was covered by existing checks introduced/updated in this branch.
• Manual review confirmed module path and contract consistency for runtime/MCP/security docs.
• Recommended before merge: npm run verify.

Breaking Changes

• None intended at external API contract level.
• Internal module boundaries changed significantly; downstream imports should use approved public paths.

Risks

• Broad refactor scope increases integration risk.
• Guardrail script strictness may surface unrelated pre-existing issues on other branches.

Follow-ups

• Consider splitting future work into smaller PR slices (runtime, MCP, guards, quality gates) to reduce review risk.