bug(ui): Azure WIF private key field missing required attribute — account saves without credentials

[rocketri]

Summary

In Settings → Accounts → Add Azure Account, when Auth Mode is set to Workload Identity Federation, the RSA Private Key textarea (#account-azure-wif-private-key) has no required attribute. The form can be submitted without entering a key.

Impact

The account record is created successfully but credentials_configured will be false. The account test will fail but there is no inline warning at submission time — the user has to discover this after the fact.

Steps to Reproduce

1. Settings → Accounts → + Add Account (Azure)
2. Leave Auth Mode as Workload Identity Federation
3. Fill in Name, Subscription ID, Tenant ID, Client ID
4. Leave the RSA Private Key textarea empty
5. Click Save Account — form submits without error

Expected Behaviour

The form should block submission and highlight the private key field when it is empty in WIF mode. Alternatively, a clear post-save warning should indicate that credentials are still needed.

🤖 Found via Playwright Azure UX test

[cristim]

Fixed and merged in PR #31 (commit 559aed9f4).

Approach

The reporter's framing — make the PEM field required — was backwards for the current architecture. Azure WIF is supposed to be secret-free: CUDly's KMS-backed OIDC signer mints a short-lived client-assertion JWT on each call, and Azure AD verifies it against the App Registration's federated-identity-credential binding. The legacy cert-based path (stored RSA private key + self-signed certificate + x5t thumbprint) was scaffolding from before the federation redesign — the IaC templates have been federation-only for a while, so the legacy path lingered as orphan code across backend, UI, and operator docs.

Rather than require the PEM, PR #31 deletes the legacy path entirely (net -345 lines). The reporter's scenario is now impossible: Azure WIF accounts have no credential field to leave blank.

Scope

• Frontend: removed the RSA Private Key textarea and cert-path instructions; dropped azure_wif_private_key from the TS credential-type union.
• Backend resolver: deleted buildAzureWIFCredential, parsePEMBlob, processPEMBlock, parseRSAKeyBlock, CredTypeAzureWIF plus their crypto/jwt imports. resolveAzureWIFCredential is now a straight delegation to BuildAzureFederatedCredential.
• Backend API: azure_wif_private_key removed from validCredentialTypes, payload schemas, and the operator-facing Azure README generator. credTypeForAccount returns "" for Azure WIF; checkCredentialPresence short-circuits empty credType with an actionable operator message for the degraded "signer not wired" state.

Verification on AWS Lambda deploy (commit 559aed9f4)

• /api/health → 200 OK, config_store + auth_service healthy
• Deployed index.html grepped: account-azure-wif-private-key → 0 matches (removed); account-azure-auth-mode → still present (WIF mode still selectable, just nothing to enter).
• Pre-commit hooks and CI all green: Go build + tests, TypeScript typecheck, Jest 1234 tests, gofmt/vet/gocyclo/gosec/trivy.

Known separately

• GCP Cloud Run deploy for this commit failed — unrelated to this PR. The failure is a pre-existing DB migration gap (column "grace_period_days" does not exist from migration 000036, the bulk-purchase-grace feature landed earlier today). GCP's Postgres instance appears to be stuck on an older schema; AWS and Azure deploys exercised the same migration code path without issue. Tracking this as a separate infra drift to fix.
• Azure Container Apps deploy was still running at comment time; will follow up if it regresses.