[RSS Phase 2] DIRAC legacy integration

# Goal

DIRAC's `ResourceStatus` and `SiteStatus` singletons consume resource status from diracx instead of the legacy RSS RPC service. Once this phase is complete, the legacy RSS read path is no longer exercised in production, even though the RPC service itself stays up until phase 3 (write API) lands.

## Consumers

Two singleton helpers wrap `ResourceStatusClient` (RPC) with a 300s in-memory cache:

- **`ResourceStatus`** — returns status for Storage Elements (4 access types), Computing Elements, and FTS. Used by `StorageFactory`, `SiteDirector`, `FTS3Utilities`, admin scripts, and others.
- **`SiteStatus`** — returns site availability. Used by `SiteDirector`, `JobScheduling`, `Matcher`, and others.

Both also expose write methods used by admin scripts and agents. All consumers go through the singletons, so migrating the singletons' backend is transparent to them.

## Can DIRAC work with the simplified (binary) status?

Phase 1 serves a binary `AllowedStatus` / `BannedStatus` model (`Active` / `Degraded` → allowed, everything else → banned).

A review of the DIRAC consumers suggests the binary model is compatible with every core read-path consumer: they either check `status in ("Active", "Degraded")` or `status != "Banned"`, which is exactly the binary split. A few minor adaptations are still expected on the consumer side.

## Sub-issues

```mermaid
graph LR
A[A. Adapt DIRAC consumers
to binary status model] --> C[C. Wire adapter into singletons
+ feature flag + integration tests]
B[B. Read adapter
diracx RSS calls + translation] --> C

style A fill:#c3e6cb
style B fill:#c3e6cb
```

Green = can start once phase 1 is merged (parallel, independent).

- A. Adapt DIRAC consumers to the binary status model
- B. Read adapter: diracx RSS calls + response translation
- C. Wire adapter into singletons + feature flag + integration tests