Environments module: finish on real IBackendApiClientProvider (not remove)

## Summary

`Elsa.Studio.Environments` is still in the solution and NuGet-shaped as a module, but its backend integration **diverged** from the supported `IBackendApiClientProvider` path and is effectively unfinished. Prefer subtractive clarity: either delete/quarantine until rewritten, or finish it on top of the real provider — do not leave a parallel broken client factory in-tree.

User-facing symptom already tracked: #326 (EnvironmentPicker never fills). This issue is the **architecture** root cause / disposition, not another “picker empty” report.

## Evidence

`EnvironmentBackendApiClientProvider.GetApiAsync`:

- `new ServiceCollection().AddDefaultApiClients(...).BuildServiceProvider()` **on every call**
- Authorization wiring **commented out**
- No `BlazorScopedProxyApi` / `ApiClientFactory` path used by `DefaultBackendApiClientProvider`
- Replaces the scoped `IBackendApiClientProvider` via `services.Replace(...)`

`AddEnvironmentsModule`:

- Registers the broken provider replacement
- **`LoadEnvironmentsStartupTask` registration is commented out** — so even when the module is added, environments are never loaded into `IEnvironmentService` (explains #326)

Sample hosts (`Host.Server` / `Host.Wasm`) do **not** call `AddEnvironmentsModule`.

Contrast: `DefaultBackendApiClientProvider` uses the shared `ApiClientFactory` + Blazor scope proxy and inherits auth from the configured HttpClient pipeline.

## Why it matters

- Accidental complexity: two incompatible ways to mint API clients; one strips auth and leaks ServiceProviders.
- Patch hazard: anyone enabling the module for multi-env gets silent empty picker (#326) and/or unauthenticated clients.
- Remote feature catalog (`RemoteFeatureProvider`) is scoped and cached forever for the circuit — a real multi-env switch would also need catalog invalidation; the current provider never gets that far cleanly.

## Proposed disposition (pick one — prefer subtractive)

**Option A — Remove / quarantine (preferred if multi-env is not near-term):**

- Stop shipping the module as supported, or mark obsolete and remove host docs/samples that suggest it works.
- Keep #326 closed as duplicate of this disposition once decided.

**Option B — Finish on the real abstraction:**

1. Reimplement environment switching by updating `IRemoteBackendAccessor` (or equivalent URL source) and **reusing** `DefaultBackendApiClientProvider` — do not build a private ServiceProvider.
2. Register and run `LoadEnvironmentsStartupTask` (or replace with an explicit load path).
3. On environment change: invalidate `RemoteFeatureProvider` catalog (and any similar scoped caches), refresh menus/features.
4. Add tests: provider does not allocate a new `ServiceProvider` per call; auth handler still attached; picker fills after startup task.

Do **not** invent a third HTTP stack.

## Related

- #326 — Enable environments module error (picker empty)
- elsa-core#7910 — `/features/installed` enablement accuracy (relevant once multi-env feature catalogs matter)

## Milestone

Unset — product call whether multi-env is in scope. Escalate to Elsa 3 Crew Lead for keep-vs-cut; Triage owns placement.

Start with EnvironmentBackendApiClientProvider.GetApiAsync, AddEnvironmentsModule, DefaultBackendApiClientProvider, and LoadEnvironmentsStartupTask; compare their registration and client-creation paths. Review the linked #326 symptom and the RemoteFeatureProvider cache implications. Done means a decided remove/quarantine or real-provider implementation, with the proposed provider, authorization, startup-loading, and environment-change tests addressed.

Written by the indexing model from the issue text.