Harden database template reuse against schema drift and concurrent rebuilds

[PhilDL]

Problem

Projects with many short-lived worktrees depend on database template reuse to keep setup and tests affordable. The reused template can currently diverge from the checked-out code, while concurrent commands may try to rebuild the same template at once.

Observed failure modes:

• A model field-storage change in *.py does not invalidate the template fingerprint, leaving the database without columns required by the current model.
• Install-time XML or data changes can require a manual reset even though the existing template still appears reusable.
• Two commands can detect the same stale template and rebuild it concurrently; one then fails while creating or replacing the database.
• A selected test profile can exit successfully after running zero tests.
• Cancelled or abandoned runs can leave databases, containers, or networks that interfere with later worktrees.

Proposed behavior

Treat template reuse as a correctness boundary.

1. Let project configuration add files or globs to the template fingerprint. Odoo projects must be able to include model schema inputs and install-time data without modifying OAD.
2. Serialize template inspection and mutation per project/template. A second process should wait for the active rebuild, then recheck the finished snapshot instead of starting another rebuild.
3. Make test profiles fail when they discover zero tests unless the profile explicitly allows an empty selection.
4. Clean resources created by an interrupted setup or test run. Existing live and shared environments must remain protected.
5. Explain the chosen action in structured output: reused, stale with changed inputs, waiting for rebuild, rebuilt, or failed cleanup.

Acceptance criteria

• Changing a configured fingerprint input marks the existing template stale and triggers one rebuild.
• Two simultaneous commands targeting the same stale template complete without duplicate-database or template-replacement conflicts.
• A non-empty test profile that executes zero tests exits non-zero and identifies the profile.
• Interrupted setup and test paths have automated cleanup coverage.
• JSON output exposes template state and lock/wait information without mixing logs into stdout.
• Documentation covers fingerprint inputs, concurrent rebuild behavior, empty-profile handling, and recovery commands.
• Automated tests cover schema-input invalidation, concurrent rebuilds, zero-test rejection, and interruption cleanup.

Compatibility

Keep current defaults for projects that do not declare extra fingerprint inputs. Shared databases and environments with live worktrees must retain their existing deletion safeguards.