studio-config-option-lifecycle

Pass a getter that retains CLI precedence through `startStudio()` and invoke it only at the intended reload boundary, such as generating Studio HTML after the `config-file-changed` browser reload. Every Studio consumer must be able to observe the new value without recreating initialized resources.

Startup-fixed options require recreating a server, compiler, watcher, or directory mapping when the value changes, so they are resolved once in `packages/cli/src/studio.ts` before `startStudio()`. Reloadable options can be re-read at a deliberate request boundary without rebuilding initialized resources.

No. If any Studio consumer requires startup-fixed behavior, the option must be startup-fixed for all consumers. Mixed lifecycle behavior is explicitly prohibited because already-created consumers cannot observe updated module state.

The consumer likely captured the value at startup and never re-read it. Verify whether the option is startup-fixed and ensure the new value is threaded through `StudioRenderJobFixedConfig` or a getter invoked at the reload boundary.

Add an explicit reset in `ConfigInternals.resetConfigOptions()` for custom module state. Options registered through `BrowserSafeApis.options` are reset automatically by `resetBrowserSafeConfigOptions()`, which runs before the changed config file executes.

Use `StudioRenderJobFixedConfig` for startup-fixed render settings captured at the Studio queue boundary. Do not call `option.getValue()` from the job processor because config state may have changed since Studio startup.