Add opt-in parameter to disable Shared Key access on hub storage accounts

🤖 [AI] Filed from findings raised in discussion #2283.

⚠️ Problem

The hub's storage accounts (hub-app.bicep, infrastructure.bicep) hardcode allowSharedKeyAccess: true with no parameter to change it. Organizations enforcing the built-in Azure Policy "Storage accounts should prevent shared key access" (common in CAF/landing-zone environments) can't deploy FinOps hubs without a policy exemption.

Nothing in the hub's pipeline actually depends on the storage account key — Data Factory already authenticates via managed identity + Storage Blob Data Contributor RBAC.

🛠️ Solution

Add an opt-in allowSharedKeyAccess parameter (bool), threaded through main.bicep → hub.bicep → the storage account resources in hub-app.bicep and infrastructure.bicep, following the same pattern as the recent opt-in Key Vault RBAC parameter (#2249). Default to true to preserve current behavior for existing deployments.

Note: allowSharedKeyAccess is a live-mutable property (confirmed via Microsoft Learn — no resource recreation needed, and it can be flipped at any time via ARM/CLI/PowerShell/portal). That's exactly why the default shouldn't just be flipped to false outright: doing so would silently change live security behavior for every existing hub on its next redeploy, potentially cutting off any client outside our pipeline that relies on the key. An opt-in parameter avoids that.

ℹ️ Additional context

Same problem class and precedent as #1067 / PR #2249 (Key Vault RBAC opt-in).

Related: #2283 (discussion)

Start with the existing allowSharedKeyAccess settings in hub-app.bicep and infrastructure.bicep, then trace the deployment flow through hub.bicep and main.bicep. Compare the parameter pattern used for the Key Vault RBAC option in #2249/PR #2249. Done means a boolean parameter defaults to true and reaches both storage account resources without changing current deployments.