Bundle mission-control into Triple-C instead of cloning from GitHub

The mission-control (Flight Control) project is being closed upstream.
This embeds the project files directly in the repo under container/mission-control/,
bakes them into the Docker image at /opt/mission-control, and copies them into place
at container startup instead of git cloning from GitHub.

Also adds missing osc52-clipboard, audio-shim, and triple-c-sso-refresh to the
programmatic Docker build context in image.rs.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

container/mission-control/.claude/skills/init-project/FLIGHT_OPERATIONS.md

@@ -0,0 +1,182 @@
+# Flight Operations Quick Reference
+
+> For full methodology docs, see [mission-control](https://github.com/msieurthenardier/mission-control)
+
+## Before You Start
+
+**Read these files in order:**
+1. `.flightops/ARTIFACTS.md` — Where and how artifacts are stored (project-specific)
+2. The **flight log** for your active flight — Ground truth for what happened
+3. The **leg artifact** you're implementing — Your acceptance criteria
+
+---
+
+## Project Crew & Phases
+
+Each phase of the Flight Control workflow has a crew definition in `.flightops/agent-crews/`:
+
+| Crew | Purpose |
+|------|---------|
+| `mission-design.md` | Crew for `/mission` (e.g., Architect validates viability) |
+| `flight-design.md` | Crew for `/flight` (e.g., Architect reviews spec) |
+| `leg-execution.md` | Crew for `/agentic-workflow` (e.g., Developer + Reviewer) |
+| `flight-debrief.md` | Crew for `/flight-debrief` (e.g., Developer provides perspective) |
+| `mission-debrief.md` | Crew for `/mission-debrief` (e.g., Architect provides perspective) |
+
+Crew files define: roles, models, interaction protocols, prompts, and signals. Customize these to change your project's agent configuration.
+
+---
+
+## Multi-Agent Workflow
+
+Legs must be implemented by a **separate Developer instance** and reviewed by a **separate Reviewer instance** (or whatever crew is defined in `leg-execution.md`). Mission Control designs legs and orchestrates — it does NOT implement code directly.
+
+The Reviewer has no knowledge of the Developer's reasoning — only the resulting changes. This separation provides objective code review. Use the `/agentic-workflow` skill in mission-control to drive this cycle.
+
+---
+
+## ⚠️ Leg Completion Checklist (MANDATORY)
+
+**You MUST complete ALL of these before emitting `[COMPLETE:leg]`:**
+
+| Step | Action |
+|------|--------|
+| 1 | All acceptance criteria verified |
+| 2 | Tests passing |
+| 3 | **Update flight log** — Add leg progress entry (see below) |
+| 4 | **Mark leg completed** — Update leg status to `completed` |
+| 5 | **Update flight** — Check off the leg in flight artifact |
+| 6 | **Commit/save with all artifact updates** |
+
+**Flight log entry MUST include:**
+- Leg status, started date, completed date
+- Changes Made (what was implemented)
+- Verification (how acceptance criteria were confirmed)
+- Any decisions, deviations, or anomalies
+
+Refer to `.flightops/ARTIFACTS.md` for exact locations and formats.
+
+---
+
+## Workflow Signals
+
+Emit at the end of your response, on its own line:
+
+| Signal | When |
+|--------|------|
+| `[HANDOFF:review-needed]` | Artifact changes ready for validation |
+| `[HANDOFF:confirmed]` | Review complete, no issues |
+| `[BLOCKED:reason]` | Cannot proceed |
+| `[COMPLETE:leg]` | Leg done AND checklist complete |
+
+---
+
+## Implementing a Leg
+
+### Pre-Implementation
+1. Read mission, flight, and leg artifacts
+2. Read flight log for context from prior legs
+3. Verify leg accuracy against existing code
+4. **Update leg status** to `in-flight`
+5. Present summary and get approval before proceeding
+
+### Implementation
+5. Implement to acceptance criteria
+6. Run tests with a timeout — use the test runner's timeout flag (e.g., `--timeout`,
+   `--test-timeout`, `-timeout`) so hanging tests fail fast instead of stalling.
+   If a test hangs, kill it, isolate the hanging test, and fix the root cause before
+   continuing. Log hanging tests and their resolution in the flight log.
+7. Run code review, fix Critical/Major issues
+8. Re-review until clean
+
+### Post-Implementation
+9. Propagate changes (project docs, flight artifacts if scope changed)
+10. **Complete the Leg Completion Checklist above**
+11. Signal `[COMPLETE:leg]`
+
+---
+
+## Just-in-Time Planning
+
+Flights and legs are created one at a time, not upfront.
+
+| Reviewing... | Should exist | Should NOT exist yet |
+|--------------|--------------|----------------------|
+| Mission | Mission artifact | Flight artifacts (only listed) |
+| Flight | Flight artifact | Leg artifacts (only listed) |
+| Leg | Leg artifact | Ready to implement |
+
+Listed flights/legs are **tentative suggestions** that evolve based on discoveries.
+
+---
+
+## Reviewing Artifacts
+
+When reviewing a mission, flight, or leg:
+
+1. Read the artifact thoroughly
+2. Validate against project goals and existing code
+3. Check for ambiguities or missing details
+4. Make changes directly if needed
+5. Describe any changes made
+6. Signal `[HANDOFF:confirmed]` if no issues, or describe changes for validation
+
+---
+
+## Code Review Gate
+
+```
+Implement → Test → Review → Fix → Re-review → Complete
+```
+
+| Severity | Action |
+|----------|--------|
+| Critical | Must fix |
+| Major | Must fix |
+| Minor | Fix if safe, else defer |
+
+Deferred issues go in the flight log.
+
+---
+
+## ⚠️ Flight Completion Checklist (MANDATORY)
+
+**When you complete the FINAL leg of a flight, also complete these steps:**
+
+| Step | Action |
+|------|--------|
+| 1 | Complete all items in the Leg Completion Checklist above |
+| 2 | **Update flight log** — Add flight completion entry with summary |
+| 3 | **Update flight status** — Set `**Status**: landed` in flight.md |
+| 4 | **Update mission** — Check off this flight in mission.md |
+| 5 | **Verify all legs** — Confirm all legs show `completed` status |
+| 6 | **Update project docs** — Ensure CLAUDE.md, README, and other docs reflect any new commands, endpoints, configuration, or APIs introduced during the flight |
+| 7 | Signal `[COMPLETE:leg]` (the orchestrator will trigger Phase 4) |
+
+The orchestrator will then:
+- Mark the PR ready for human review
+
+The flight debrief is a separate step run via `/flight-debrief`, which transitions the flight from `landed` to `completed`.
+
+---
+
+## Database Schema Changes
+
+When a flight modifies database schemas:
+
+1. **Include migration steps in the leg** — schema changes need explicit CREATE/ALTER statements or migration commands
+2. **Verify migrations run** — acceptance criteria must include confirming the migration executed successfully against the live database
+3. **Update SCHEMA docs** — if the project maintains a SCHEMA reference, update it in the same leg that creates the migration
+4. **Test against real DB** — unit tests with mocks are not sufficient for schema changes; verify against the actual database
+
+A table defined in SCHEMA but never created via migration is a gap — treat schema documentation and migration execution as a single atomic operation.
+
+---
+
+## Key Principles
+
+1. **Flight log is ground truth** — Read it first, update it always
+2. **Never modify in-flight legs** — Create new ones instead
+3. **Binary acceptance criteria** — Met or not met
+4. **Log everything** — Decisions, deviations, anomalies
+5. **Signal clearly** — End of response, own line