v0.7.1 — dev container venv race + stale-venv self-heal

A patch release addressing two adopter-blocking dev-container bugs surfaced when the first real project (ai-powered-lead-gen-mvp) scaffolded from v0.7.0.

Fixes

• #99 fix(template): self-heal stale .venv and wait for postCreateCommand.
  • devcontainer.json now declares "waitFor": "postCreateCommand". Without it, VS Code attaches before post-create.sh finishes, and the Python + Ruff extensions try to spawn ${workspaceFolder}/.venv/bin/python before make sync has created it. Symptom: Ruff: spawn .venv/bin/python ENOENT on first attach.
  • make sync-python now self-heals a non-runnable .venv (e.g. dangling symlink after a base-image upgrade or device migration). If .venv/bin/python --version fails, the venv is removed before re-syncing. uv sync alone wrote lockfile metadata but did not detect or repair a broken interpreter.
  • New "Dev container" section in KNOWN-ISSUES.md documenting both symptoms and recovery steps for adopters whose containers were built before this fix.

Why this matters for adopters

Anyone who scaffolded from v0.7.0 and opened the project in a VS Code dev container could hit the Ruff ENOENT race. After upgrading to v0.7.1:

• Fresh renders: Dev Containers: Rebuild Container once and the editor attach now blocks until post-create finishes.
• Existing renders: pull the two changed files (devcontainer.json, Makefile.fragments/sync.mk) or re-render and merge per docs/UPDATING.md.

Upgrade

For copier-rendered projects:

copier update --trust --skip-answered --vcs-ref v0.7.1

For cookiecutter-rendered projects, no in-place upgrade flow ships; either re-render and merge per docs/UPDATING.md or cherry-pick the two-file change.

Full diff: v0.7.0...v0.7.1