Release module metadata locks before Odoo

[cbusillo]

Summary

• release the parent psycopg metadata transaction before launching Odoo module install/update subprocesses;
• apply the same connection boundary to OpenUpgrade state snapshots and commands;
• preserve final cleanup on command success/failure and document the shared lock contract;
• add regressions for normal module updates, command failure, OpenUpgrade snapshots, and OpenUpgrade execution.

Live canary evidence

On July 30, 2026, odoo-tenant-cm-website PR #65 reached the real Odoo -u launchplane_settings,cm_website,disable_odoo_online command with the correct artifact, addon paths, and filestore environment. PostgreSQL then timed out on ALTER TABLE ir_module_module because the parent data-workflow process still held its metadata-query transaction open on the same table.

Closing the cached connection before the child process releases that AccessShareLock and prevents the workflow from blocking its own DDL. This is a shared devkit runtime defect proven by the preview canary; no tenant workaround is included.

Validation

• uv run python -m unittest discover -s tests — 227 tests passed, 1 expected skip
• focused data-workflow suite — 9 tests passed
• uv run ruff check . passed
• uv run ruff format --check . passed
• uv build passed
• uv run platform --help passed
• independent review found and the patch fixed the analogous OpenUpgrade lock path

JetBrains inspection was attempted twice but remained tooling-unknown because the helper could not establish a content root (project_content_roots_missing); it reported no code finding. The helper-generated .idea changes were removed.

Related to #94, cbusillo/launchplane#1898, and cbusillo/odoo-tenant-cm-website#6. Keep #94 open until the merged devkit revision passes the final two-revision website preview canary.