Skip component credential config when app is in multi-tenant mode

[gandalf-at-lerian]

Context

When applications run in multi-tenant mode, lib-commons still requires the operator to configure single-tenant credentials for PostgreSQL, Valkey, MongoDB and RabbitMQ. In this scenario, schemas and vhosts from those configs are never used at runtime — the app resolves component connections per-tenant via tenant-manager.

This creates real friction:

• Drift risk: credentials updated in tenant-manager but not in app env (or vice-versa)
• Onboarding pegadinha: new devs configure local PG/Mongo/Rabbit that never gets touched
• Misleading health: app boots green with credentials nobody actually uses

Proposal

Make component credential config conditional on tenant mode in lib-commons.

Sketch:

• Introduce (or formalize) a flag like tenant.mode = single | multi
• In multi, skip bind/validate for the database, cache and mq blocks
• In multi, the only required infra config becomes tenant-manager (URL + auth + cache TTL) — replaces N configs with 1
• Migrations runner should fetch the connection from the tenant target instead of static env (provisioning already routes through tenant-manager)
• Keep the single-tenant path intact for local dev and tests — behavior is purely conditional on mode

Open points for the leads to evaluate

• Bootstrap / readiness: app must be ready before any tenant resolves. Readiness probe shouldn't depend on "at least 1 active tenant" — separate app health from tenant-resolution health.
• Failure mode: what does the app do at boot if tenant-manager is unreachable? Fail fast vs. degraded ready?
• Config schema impact: how do we keep retrocompatibility for apps that haven't migrated yet?
• Naming: tenant.mode vs reusing an existing flag — align with what's already in the codebase.
• Scope: does this apply uniformly to PG, Valkey, Mongo and Rabbit, or are there blocks that legitimately stay app-level even in MT?

Discussion started on Slack #tech-leads (2026-05-07).

Requested by: @ferr3ira-gabriel