Upgrade a configured module list with its installed local dependencies

[shiny-code-app]

Why

A deploy never loaded data changes in a tenant's dependency addons. Launchplane's post-deploy names the artifact's install list in ODOO_UPDATE_MODULES, and Odoo's -u upgrades a module's dependents, not its dependencies. So a new cron, view or record in an addon such as OPW's shopify_sync stayed unloaded until the next restore, while its Python code was already live. Tonight's opw/testing deploy is the evidence (#142): opw_custom was upgraded and shopify_sync wasn't, so the cron from odoo-tenant-opw#170 doesn't exist there.

What changed

• When ODOO_UPDATE_MODULES names modules, update_addons also upgrades their installed local dependencies: the same dependency closure AUTO already uses, now one helper shared by both.
  • Core and enterprise addons are never added, and neither are uninstalled modules.
  • Callers that pass explicit_modules still get exactly what they pass.
• The log names the added dependencies.

Verification

• New test: a configured tenant_core whose local dependency tenant_helper is installed upgrades both. The core sale and the uninstalled tenant_deep are not added.
• The existing test for a configured list with no local dependencies is unchanged and still passes.
• tests.test_odoo_data_workflows (59 tests) and the full unittest discover (321) pass; ruff check and format are clean.

Rollout

Tenants pick this up when their devkit pin moves and they publish a new artifact. On OPW that loads #170's Check Product Payloads Offline cron on the next testing deploy.

Refs #142

[shiny-code-app]

Review by another model: OpenAI gpt-6.1-sol, read-only against this branch. It checked for unwanted upgrades (core, enterprise, uninstalled or non-tenant modules), deploys this could break, and explicit_modules callers. Result: none.