resource group: support degrade to default RU group

## Enhancement
In Starter mode, when the resource group controller fails to initialize or fetch the resource group, the system should fall back to the default RU group instead of failing the request immediately.

### Background
In Starter deployments, temporary resource manager failures should not block normal request processing.

### Constraints
- Degraded fallback is enabled only when `degradedRUSettings` is configured.
- The fallback applies only to `GetResourceGroup` and only for transient RM failures.
- Use the degraded group only for retryable cases such as leader changes, gRPC `Unavailable`, or server-side `DeadlineExceeded` while the caller context is still active.
- Do not use degraded fallback for:
- resource group not found
- caller `context.Canceled`
- caller `context.DeadlineExceeded`
- gRPC `Canceled`
- other non-retryable errors such as `PermissionDenied`
- Once RM recovers, the client should return the real resource group again instead of continuing to use the degraded one.
- `ErrClientGetResourceGroup` must preserve and unwrap the underlying error so upper layers can inspect it with `errors.Is` and gRPC status checks.
- A nonexistent `SwitchGroup` target must not trigger a switch.

### Error Classification
The detailed decision logic for different error types is refined in [tikv/pd#11009](https://github.com/tikv/pd/pull/11009). That PR defines which errors are treated as transient and eligible for degraded
fallback, and which errors must be propagated unchanged to the caller.

Start at the resource group controller's GetResourceGroup path and inspect degradedRUSettings and ErrClientGetResourceGroup. Read tikv/pd#11009 for the transient-error classification. Done means eligible Starter requests use the default RU group only during retryable RM failures, recover the real group afterward, preserve errors for inspection, and avoid switching to nonexistent targets.

Written by the indexing model from the issue text.