Launchpad provider turn-on: a managed-policy refusal answers 500 internal_error #176

Found by the independent review of the v0.1.7 rebuild (#172, PR #174, row 18). Same family as #128 (a refusal surfaced as internal_error), but on a different path.

What happens. The Launchpad's provider turn-on writes through settings.updateSettingsWith(...) (apps/server/src/lazurio/providerRefresh.ts:194-198). From v0.1.7 every settings write is vetted by the managed policy (managed.vetWrite and managedProviders.vetWrite in apps/server/src/serverSettings.ts), and a refusal fails with ServerSettingsError. The route maps every ServerSettingsError to a 500 internal_error (apps/server/src/lazurio/providerRefreshRoute.ts:42), so a policy that disallows a provider or locks its enabled reaches the Launchpad and the logs as an internal error. The person cannot tell that the Organization's policy refused it.

No test covers the refusal on this path: providerRefresh.test.ts and providerRefreshRoute.test.ts provide ManagedPolicy.layerTest() without a policy. The only refusal test is row 15's at the settings layer (modelRecommendation.test.ts, "the overlay's settings writes stay inside the managed policy").

Impact today. None on Lazurio Environments: Lazurio installs no managed policy file (/etc/t3code/policy.json on Linux). It matters on any policy-managed install.

Proposed fix.

1. In the route, answer a policy refusal (ServerSettingsError with operation write-managed-setting or use-disallowed-provider) with 403 and a body that names the setting or provider instance; keep internal_error for real I/O failures.
2. Add a providerRefresh.test.ts case under a policy that disallows Codex: enable: true is refused and the settings file stays unchanged.

Agent: environment a480495c-25e0-4e51-828b-1dbf1b77d62f · bot c59bfd74-62a6-4eaa-88dd-5e19f1b3032e