docs(multitenant): define Step 2 resource routing and security architecture

[andrea-putzu]

List of Changes

• Added the Step 2 requirements, provisional architecture, and security rules for runtime tenant resource routing and strict isolation (AR / PNPG), including Cosmos DB Mongo credential handling via Key Vault-backed connection strings.
• Introduced two new shared libraries:
  • selfcare-sdk-tenant: TenantContext (request-scoped, fail-closed tenant resolution) and TenantRegistry, which parses a single JSON registry (one entry per tenant with account, database, connectionStringEnvVar) and resolves each tenant's Mongo connection string from an environment variable, sanitizing HTML-encoded & in Cosmos connection strings.
  • selfcare-sdk-tenant-mongodb: a CDI producer (TenantMongoClientProducer) that builds one ReactiveMongoClient per configured tenant, replicating Quarkus' own codec setup (default BSON codecs + automatic POJO codec provider) so Panache entities are correctly encoded/decoded, plus TenantMongoDatabaseResolver to pick the right Mongo database per request based on the current tenant.
• Updated apps/onboarding-ms:
  • Added tenantId to the Onboarding and Token entities.
  • Updated OnboardingRepository and added TokenRepository to route all Mongo queries through the tenant-aware client/database instead of a single global connection string.
  • Removed the legacy MONGODB_CONNECTION_STRING / quarkus.mongodb.connection-string configuration; the service now resolves the correct dedicated Cosmos DB Mongo account (AR or PNPG) purely from the tenant registry at startup.
  • Added the JSON tenant registry configuration and tenant.supported-tenants property.
• Updated Terraform (infra/resources/onboarding-ms/*) for all environments (dev/uat/prod, AR/PNPG) to inject MONGODB_CONNECTION_STRING_AR / MONGODB_CONNECTION_STRING_PNPG from Key Vault instead of the single legacy connection string secret.
• Documented Step 1 backfill tooling and strict-mode gates as prerequisites for database consolidation, and added the Database_identification.md doc explaining how the correct Mongo database is resolved at runtime.

Motivation and Context

Step 2 formalizes the architecture, security controls, and concrete implementation required to move onboarding-ms from a single shared Cosmos DB Mongo database to a shared backend that safely serves two dedicated tenants (AR and PNPG).

The documentation establishes a single validated tenant context for resource selection, prevents default-tenant fallbacks, and preserves tenant identity across synchronous workflows. The implementation removes any direct, tenant-unaware Mongo configuration from the application: instead of a single MONGODB_CONNECTION_STRING, the service reads a dynamic JSON tenant registry at startup and resolves, per request, which dedicated Cosmos DB Mongo account/database to use based on the authenticated tenant — never falling back to a default database.

It also clarifies the secret boundary: Container Apps use their managed identity to resolve Key Vault-backed secrets, while Cosmos DB Mongo clients authenticate with the injected, tenant-specific connection strings. Mongo authentication through Managed Identity remains explicitly out of scope.

How Has This Been Tested?

• Ran mvn -f libs/selfcare-sdk-tenant/pom.xml test and mvn -f libs/selfcare-sdk-tenant-mongodb/pom.xml test (unit tests for TenantRegistry and TenantMongoDatabaseResolver).
• Ran mvn -f apps/onboarding-ms/pom.xml clean install (unit tests, including Cucumber suites) after wiring the tenant-aware repositories.
• Verified locally in quarkus:dev that onboarding read/write operations are routed to the correct dedicated Cosmos DB Mongo account (AR vs PNPG) based on the resolved tenant, and that the Panache codec/connection-string issues encountered during development (HTML-encoded &, missing POJO codec registry) are resolved.
• Reviewed the Step 2 documents against the existing Step 1 requirements, architecture, security rules, Terraform modules, and Maven application configuration.

Screenshots (if appropriate):

Not applicable; this pull request contains documentation, shared libraries, and application/configuration changes only.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.