mount an azure files share at /var/lib/sop so config and billing state survive restarts

[gerardrecinto]

The Container App had no volume, so /var/lib/sop was the container's own disk. config.json, stores and billing state (plan upgrades, webhook dedupe) were wiped on every restart or new revision. This adds a Standard LRS storage account with a joltrin-data file share, registers it on the Container Apps environment, and mounts it at /var/lib/sop with uid/gid 65532 (the image's nonroot user) and nobrl.

Validated with az bicep build, az deployment group validate and a what-if against joltrin-prod-rg: it creates the storage account, file service, share and environment storage and modifies the container app. Nothing is deleted.

Not covered here: a first-admin bootstrap. With a fresh share there is still no config.json, and first-run setup only accepts loopback requests, so nobody can log in on the live app yet. That is a server change and gets its own PR. I have not tested the embedded B-Tree engine against SMB-backed storage under load, so check that after the first deploy before taking real payments.

Thanks, Gerard Recinto

[github-actions]

Gemini PR Review

Reviewed commit: e0be0ed010218607b80198f39d77076969248fd9
Verdict: PASS

• The storage account (infra/azure/modules/storage.bicep) is configured with allowSharedKeyAccess: true, and its account key is retrieved and used by the managed environment (infra/azure/modules/container-apps-environment.bicep) to mount the Azure File share. While necessary for Azure Container Apps to mount file shares, this relies on the security of the storage account key. The comment within the code explains this necessity and notes that no other components use this storage account, which helps to mitigate broader risk, but it's a less secure access mechanism than identity-based access when that's available.