BGP APIs hidden by flag named `routed.network.vpc.enabled`, return misleading 'not found' error

outed/BGP APIs gated by a VPC-named flag; silent + misleading

**Title:** `routed.network.vpc.enabled` gates BGP / routed-isolated-network APIs (not VPC-specific); disabling VPC silently removes them with a misleading error

## Summary

The global setting **`routed.network.vpc.enabled`** ("If true, the Routed network and VPC are enabled in the zone.") gates a large set of APIs that are **not VPC-specific** — the entire BGP dynamic-routing and routed-**isolated**-network command set. When it is `false`, `RoutedIpv4ManagerImpl.getCommands()` returns an empty list, so ~42 commands never register with API Discovery:

`createASNRange`, `createBgpPeer`, `updateBgpPeer`, `deleteBgpPeer`, `listBgpPeers`, `dedicateBgpPeer`, `releaseBgpPeer`, `changeBgpPeersForNetwork`, `changeBgpPeersForVpc`, `listASNRanges`, `listASNumbers`, `releaseASNumber`, `createIpv4SubnetForZone` / `...ForGuestNetwork` (+ list/update/delete/dedicate/release variants), routing-firewall-rule commands, etc.

There are two problems:

### 1. Conflation of two independent features under one VPC-named flag
Routed **isolated** networks with BGP dynamic routing are a distinct capability from **VPC**. An operator who wants BGP-routed isolated networks but does **not** want to offer VPC (a common, reasonable posture) has no way to enable one without the other. Disabling VPC via this flag also disables routed isolated networks + all BGP/ASN APIs. A VPC toggle should not gate non-VPC functionality; these should be separately controllable (or the flag renamed/split, e.g. `routed.network.enabled` vs `vpc.enabled`).

### 2. Silent removal + misleading error (major debugging cost)
When the flag is `false`:
- The ~42 commands are **absent from `listApis`** with no indication why.
- Calling one returns **"The given command `createASNRange` either does not exist, is not available for user, or not available from ip address ..."** and `listApis name=createASNRange` returns HTTP 530 **"Api Discovery plugin was unable to find an api by that name."**
- The startup log still shows `RoutedIpv4ManagerImpl` registering as an extension and being "Discovered" — so everything *looks* fine.

None of these mention that a **feature toggle** is responsible. There is no "this API is disabled because `routed.network.vpc.enabled=false`" message. This makes the cause extremely hard to find — the symptoms all point at a broken/missing feature or a permissions problem, not a config flag. (In our case it took an extensive investigation before locating the gate in `RoutedIpv4ManagerImpl.getCommands()`.)

## Reproduce

1. Any CloudStack 4.20+ (confirmed 4.22.0.0 and 4.22.1.0).
2. Set global `routed.network.vpc.enabled = false` (or disable VPC in a way that sets it false) and restart the management server.
3. As root admin: `listApis` — the BGP/ASN/Ipv4-subnet commands are gone; `listApis name=createBgpPeer` → 530; calling `createBgpPeer` → "not available for user".
4. Set `routed.network.vpc.enabled = true`, restart — the commands reappear.

Mechanism: `server/src/main/java/org/apache/cloudstack/network/RoutedIpv4ManagerImpl.java`, `getCommands()`:
```java
public List> getCommands() {
final List> cmdList = new ArrayList<>();
if (!RoutedNetworkVpcEnabled.value()) { // "routed.network.vpc.enabled"
return cmdList; // hides ALL routed/BGP/ASN/IPv4-subnet commands
}
...
}
```

## Suggested fixes
1. **Separate the toggles** — a distinct enable for routed isolated networks / BGP dynamic routing, independent of VPC (or rename `routed.network.vpc.enabled` and split it), so BGP-routed-without-VPC is possible.
2. **Make the disabled state discoverable** — when a command is unavailable due to a feature flag, return an error that names the flag (e.g. "API disabled; set `routed.network.vpc.enabled=true`"), rather than the generic "does not exist / not available for user". At minimum, document that this flag gates the BGP/ASN/routed-subnet API set.

## Environment
Observed on CloudStack 4.22.1.0 and 4.22.0.0 (stock, download.cloudstack.org, Ubuntu 24.04, OpenJDK 17, MariaDB 10.11), KVM. The gating code is identical across these versions — it is a config-flag behaviour, not version-specific.

Beginne in server/src/main/java/org/apache/cloudstack/network/RoutedIpv4ManagerImpl.java, insbesondere mit getCommands(), und reproduziere das Verhalten mit routed.network.vpc.enabled=false unter Verwendung von listApis und createBgpPeer. Prüfe, wie das Flag die routed-, BGP-, ASN- und IPv4-subnet-Befehle steuert. Als abgeschlossen gilt, dass die unabhängigen Fähigkeiten angemessen gesteuert werden können und ein deaktivierter Befehlsstatus erkennbar ist, statt als fehlend gemeldet zu werden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.