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/docs/flights.md

@@ -0,0 +1,462 @@
+# Flights
+
+Flights are the balanced layer of Flight Control—technical enough for implementation, readable enough for humans. A flight and its flight plan are synonymous: the document *is* the plan.
+
+## What is a Flight?
+
+A flight translates mission outcomes into technical specifications. Flights are:
+
+- **Technically scoped**: Bounded implementation work
+- **Checklist-driven**: Pre-flight, in-flight, and post-flight phases
+- **Adaptive**: Living documents that evolve with understanding
+
+### Flight vs. Mission vs. Leg
+
+| Aspect | Mission | Flight | Leg |
+|--------|---------|--------|-----|
+| Question | Why? | What & How? | Do this |
+| Audience | Stakeholders | Developers/AI | AI agents |
+| Flexibility | High | Medium | Low |
+| Updates | Rarely | As needed | Never (create new) |
+
+## Flight Structure
+
+Every flight has three sections corresponding to its lifecycle:
+
+```markdown
+# Flight: {Title}
+
+## Mission Link
+Parent mission and relevant success criteria.
+
+---
+
+## Pre-Flight
+
+### Objective
+What this flight accomplishes.
+
+### Open Questions
+- [ ] Question needing resolution
+- [ ] Another question
+
+### Design Decisions
+Choices made and their rationale.
+
+### Prerequisites
+What must be true before execution begins.
+
+### Pre-Flight Checklist
+- [ ] Questions resolved
+- [ ] Design decisions documented
+- [ ] Prerequisites verified
+- [ ] Legs defined
+
+---
+
+## In-Flight
+
+### Technical Approach
+How the objective will be achieved.
+
+### Checkpoints
+Key milestones during execution.
+
+### Adaptation Criteria
+When to deviate from plan.
+
+### Legs
+Links to implementation legs.
+
+---
+
+## Post-Flight
+
+### Completion Checklist
+- [ ] All legs completed
+- [ ] Integration verified
+- [ ] Tests passing
+- [ ] Documentation updated
+
+### Verification
+How to confirm the flight achieved its objective.
+
+### Retrospective Notes
+What was learned during this flight.
+```
+
+## Pre-Flight Phase
+
+Pre-flight is about readiness. No implementation happens here—only planning.
+
+### Open Questions
+
+Capture unknowns that need resolution before execution:
+
+```markdown
+### Open Questions
+- [ ] Should we use JWT or session-based auth?
+- [ ] What OAuth providers do we need to support?
+- [ ] How long should sessions remain valid?
+```
+
+Questions should be:
+- **Specific**: Clear what information is needed
+- **Blocking**: Execution can't proceed without answers
+- **Resolvable**: Someone can answer them
+
+Check off questions as they're resolved and document answers in Design Decisions.
+
+### Design Decisions
+
+Record choices and rationale:
+
+```markdown
+### Design Decisions
+
+**Authentication Method**: JWT tokens
+- Rationale: Stateless, works across services
+- Trade-off: Token revocation more complex
+- Decided by: Security team review
+
+**Session Duration**: 7 days with refresh
+- Rationale: Balance security and convenience
+- Trade-off: Longer exposure window
+- Decided by: Product requirements
+```
+
+Design decisions prevent relitigating settled questions and help future maintainers understand *why*.
+
+### Prerequisites
+
+List conditions required for execution:
+
+```markdown
+### Prerequisites
+- [ ] Database schema migrations ready
+- [ ] API authentication middleware exists
+- [ ] Test environment configured
+- [ ] Security review of approach completed
+```
+
+Prerequisites are external dependencies. If they're not met, the flight can't begin safely.
+
+### Pre-Flight Checklist
+
+The gate check before execution:
+
+```markdown
+### Pre-Flight Checklist
+- [ ] All open questions resolved
+- [ ] Design decisions documented with rationale
+- [ ] Prerequisites verified
+- [ ] Legs defined with acceptance criteria
+- [ ] Estimated scope is reasonable
+```
+
+When all items are checked, the flight moves from `planning` to `ready`.
+
+## Flight Briefing
+
+Before execution begins, create a **flight briefing** to align the crew:
+
+```markdown
+# Flight Briefing: {Title}
+
+## Mission Context
+How this flight contributes to the mission.
+
+## Objective
+What this flight will accomplish.
+
+## Key Decisions
+Critical design decisions the crew should know.
+
+## Risks
+Known risks and mitigation strategies.
+
+## Legs Overview
+Summary of legs with complexity notes.
+
+## Success Criteria
+How we'll know the flight succeeded.
+```
+
+The briefing is created when the flight moves to `ready` status.
+
+## In-Flight Phase
+
+In-flight is execution. Legs are being worked, progress is tracked in the [flight log](flight-logs.md).
+
+### Technical Approach
+
+Document *how* the objective will be achieved:
+
+```markdown
+### Technical Approach
+
+1. Create user model with email/password fields
+2. Implement registration endpoint with validation
+3. Add login endpoint with JWT generation
+4. Create middleware for protected routes
+5. Add password reset flow
+```
+
+This bridges design decisions to concrete implementation without being leg-level specific.
+
+### Checkpoints
+
+Define milestones for progress tracking:
+
+```markdown
+### Checkpoints
+- [ ] User registration working end-to-end
+- [ ] Login returning valid tokens
+- [ ] Protected routes rejecting invalid tokens
+- [ ] Password reset emails sending
+```
+
+Checkpoints help identify if a flight is on track or needs intervention.
+
+### Adaptation Criteria
+
+When should the plan change?
+
+```markdown
+### Adaptation Criteria
+
+**Divert if**:
+- Security vulnerability discovered in approach
+- External API changes break integration
+- Performance testing reveals blocking issues
+
+**Acceptable variations**:
+- Minor API changes for developer experience
+- Additional validation rules
+- Extended error handling
+```
+
+Explicit adaptation criteria prevent both rigid adherence to bad plans and unnecessary scope creep.
+
+### Legs
+
+Reference the implementation legs:
+
+```markdown
+### Legs
+- [x] `create-user-model` - completed
+- [x] `registration-endpoint` - completed
+- [ ] `login-endpoint` - in-flight
+- [ ] `auth-middleware` - planning
+- [ ] `password-reset` - planning
+```
+
+### Flight Log
+
+During execution, maintain a [flight log](flight-logs.md) alongside this document. The flight log records:
+
+- **Leg progress**: When legs start and complete, with summaries of changes
+- **Decisions**: Choices made during execution not in the original plan
+- **Deviations**: Departures from the planned approach and why
+- **Anomalies**: Unexpected issues or behaviors encountered
+
+The flight log is essential for:
+- Providing continuity when work resumes after interruption
+- Informing the creation of subsequent legs
+- Enabling meaningful post-flight retrospectives
+
+## Post-Flight Phase
+
+Post-flight is verification and learning. Implementation is complete; now confirm success.
+
+### Completion Checklist
+
+Verify all work is finished:
+
+```markdown
+### Completion Checklist
+- [ ] All legs marked completed
+- [ ] Code merged to main branch
+- [ ] Integration tests passing
+- [ ] Documentation updated
+- [ ] No blocking issues remaining
+```
+
+### Verification
+
+How to confirm the flight succeeded:
+
+```markdown
+### Verification
+
+**Manual verification**:
+1. Create new user account
+2. Log in with credentials
+3. Access protected endpoint
+4. Log out and verify token invalid
+
+**Automated verification**:
+- `npm run test:auth` passes
+- `npm run test:e2e` auth flows pass
+```
+
+### Retrospective Notes
+
+Capture learnings for future flights:
+
+```markdown
+### Retrospective Notes
+
+**What went well**:
+- JWT library well-documented
+- Security review caught edge case early
+
+**What could improve**:
+- Underestimated password reset complexity
+- Should have spiked OAuth earlier
+
+**For next time**:
+- Include OAuth research in pre-flight
+- Add explicit leg for error handling
+```
+
+## Flight Lifecycle
+
+Flights progress through defined states:
+
+### States
+
+```
+planning ──► ready ──► in-flight ──► landed ──► completed
+                           │
+                           └──► aborted
+```
+
+**planning**
+Pre-flight phase. Questions being resolved, design decisions being made.
+
+**ready**
+Pre-flight checklist complete. All prerequisites met. Ready to execute.
+
+**in-flight**
+Legs actively being executed. Checkpoints being reached. Flights may be modified during this phase (e.g., changing planned legs) as long as the flight log captures the change and rationale.
+
+**landed**
+All legs complete. Verification passed. Flight achieved its objective. Ready for debrief.
+
+**completed**
+Debrief done. Flight fully wrapped up and artifacts updated.
+
+**aborted**
+Flight cancelled. Changes are rolled back. Document the reason for future reference.
+
+### In-Flight Modifications
+
+Flights can be modified while `in-flight` — for example, when planned legs need to change due to discoveries during execution. This is not a separate state; simply update the flight artifact and record the change and rationale in the flight log.
+
+**Create a new flight when:**
+- A completely new objective emerges
+- The discovered work is independent of the current flight's goal
+- The new work serves different mission success criteria
+
+### State Transitions
+
+| From | To | Trigger |
+|------|----|---------|
+| planning | ready | Pre-flight checklist complete |
+| ready | in-flight | First leg begins |
+| in-flight | landed | All legs complete |
+| in-flight | aborted | Flight cancelled, changes rolled back |
+| landed | completed | Debrief complete |
+
+## Connecting to Parent Mission
+
+Flights serve missions. Each flight should clearly link to:
+
+```markdown
+## Mission Link
+
+**Mission**: [Secure User Authentication](../mission.md)
+
+**Contributing to criteria**:
+- [ ] Users can create accounts with email/password
+- [ ] Session management handles concurrent logins
+```
+
+This traceability ensures flights aren't orphaned work—they connect to meaningful outcomes.
+
+## Connecting to Child Legs
+
+Flights generate legs. The flight defines *what* needs to happen; legs define the *exact* implementation steps.
+
+A well-structured flight enables AI agents to execute legs without needing clarification:
+
+**Flight provides**:
+- Technical approach and patterns
+- Design decisions and constraints
+- Context about the broader system
+
+**Legs consume**:
+- Specific task to complete
+- Acceptance criteria to meet
+- Context from flight document
+
+## Common Pitfalls
+
+### Skipping Pre-Flight
+
+Rushing to implementation creates problems. Pre-flight exists to:
+- Surface hidden complexity
+- Align on approach before work begins
+- Identify blocking dependencies
+
+A thorough pre-flight prevents mid-flight crises.
+
+### Over-Specifying
+
+Flights should guide, not constrain. Leave room for:
+- Implementation details discovered during work
+- Better approaches found during execution
+- Minor adjustments that don't affect outcomes
+
+### Ignoring Adaptation Criteria
+
+When circumstances change, adapt the plan. Flights that ignore reality become fiction. Use adaptation criteria to decide when to divert.
+
+### Skipping Post-Flight
+
+Post-flight isn't bureaucracy—it's learning. Retrospective notes prevent repeating mistakes. Verification confirms the flight actually succeeded.
+
+## Flight Debrief
+
+After a flight lands (or diverts), create a **flight debrief** for retrospective analysis:
+
+```markdown
+# Flight Debrief: {Title}
+
+## Outcome Assessment
+What the flight accomplished and which mission criteria it advanced.
+
+## What Went Well
+Effective patterns during execution.
+
+## What Could Be Improved
+Process and technical recommendations.
+
+## Deviations and Lessons
+What changed from the plan and why.
+
+## Recommendations
+Top 3-5 most impactful improvements.
+
+## Action Items
+Follow-up work and improvements.
+```
+
+The debrief enables continuous improvement and informs future flights.
+
+## Next Steps
+
+- [Flight Logs](flight-logs.md) — Recording execution progress and decisions
+- [Legs](legs.md) — Learn to write AI-optimized implementation steps
+- [Workflow](workflow.md) — See how flights flow into legs