Migrate production deploy to `aspire deploy`

[davidortinau]

Tracking issue surfaced during PR #166 production deploy.

Context

During PR #166's deploy window we attempted to flip the production deploy tool from azd deploy to aspire deploy. The attempt blocked on two real issues:

1. AppHost does not register AddAzureContainerAppEnvironment. src/SentenceStudio.AppHost/AppHost.cs lines 5–9 contain an explicit note that the registration was removed because it changes azd's manifest template format incompatibly with existing azd env vars. Switching to aspire deploy requires uncommenting builder.AddAzureContainerAppEnvironment("aca-env").WithAzdResourceNaming();.

2. aspire deploy prompts for all 7 parameters interactively: openaikey, elevenlabskey, jwtkey, githubpat, dbUser, dbPassword, syncfusionkey. azd stores these in its env state; aspire deploy doesn't read azd state. A non-interactive path (env vars, config file, or keyvault refs) needs to be wired before aspire-deploy is viable.

Work required

• Uncomment AddAzureContainerAppEnvironment("aca-env").WithAzdResourceNaming() in AppHost.cs
• Wire the 7 secret parameters for non-interactive deploy (preferred: Key Vault refs; acceptable: env-var convention documented in runbook)
• Verify the new manifest format targets the existing azd-provisioned ACA resources (not a reprovision)
• Dress-rehearse aspire deploy against a staging env or disposable RG before touching production
• Flip docs/deploy-runbook.md to recommend aspire deploy and keep azd deploy documented as fallback
• Validate against the Flexible Server (no mount/reprovision risk)

Why this is worth doing

• aspire deploy is incremental (no reprovision), faster than azd deploy for code-only changes
• Keeps deploy tooling aligned with Aspire's evolving story rather than diverging

Why we didn't bundle it into PR #166

Separating concerns — PR #166 is the server-side App Insights slice and was already dress-rehearsed for that scope. A deploy-tool migration needs its own rehearsal.

Context: PR #166