Context

PR #65 shipped C4 Mermaid diagram templates (#50). The /handover skill already generates a structured assessment when adopting an external repo into the ApexStack portfolio. This issue wires up auto-generation of a stub L2 container diagram alongside the existing assessment output.

User Story

As a CTO adopting a new repo into my ApexStack portfolio, I want /handover <project> to produce a starter projects/<name>/architecture/container.md file with detected containers pre-filled (from package.json, Dockerfile, docker-compose.yml, etc.), so I don't have to manually open the template and re-type what's obvious from the repo's surface.

Acceptance Criteria

• /handover writes projects/<name>/architecture/container.md alongside the existing projects/<name>/handover-assessment.md
• Containers pre-filled from repo signals:
  • package.json with Next.js / React / Express → Web App / API containers
  • docker-compose.yml services → one container per service
  • Dockerfile at repo root → one Container with detected base image
  • Database hints (drizzle.config.ts, prisma/schema.prisma, DATABASE_URL in .env.example) → ContainerDb
  • Redis / cache / queue hints → respective containers
• Generated file is a valid starting point — user can render it on GitHub immediately and then refine
• If projects/<name>/architecture/container.md already exists, skip (don't overwrite)
• Skill output points the user at the generated file with a "review and refine" note

Out of Scope

• L1 context auto-gen (L1 requires external-system knowledge the repo doesn't always expose)
• L3+ diagrams (see follow-up for Structurizr DSL)
• Non-Mermaid formats
• Perfect accuracy — this is a starting point, not a final diagram

Related

• Shipped templates in feat: architecture diagram support in documentation — C4 model #50 / PR to-be-numbered
• Decision rationale: docs/agdr/AgDR-0003-mermaid-c4-for-diagrams.md