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.

Commencez dans server/src/main/java/org/apache/cloudstack/network/RoutedIpv4ManagerImpl.java, en particulier dans getCommands(), et reproduisez le comportement avec routed.network.vpc.enabled=false en utilisant listApis et createBgpPeer. Examinez comment le flag contrôle les commandes routed, BGP, ASN et IPv4-subnet. Le travail est terminé lorsque les capacités indépendantes peuvent être contrôlées de manière appropriée et qu’un état de commande désactivée peut être découvert plutôt que signalé comme manquant.

Rédigé par le modèle d'indexation à partir du texte de l'issue.