[Bug] gem4gov-cli: the compliance regime has no effect on the engine's feature posture — FedRAMP High, IL4 and IL5 print the same list and apply the same engine_features.yaml

## Bug Description
`gem4gov app update-compliance` and the onboarding flow both branch on the compliance regime, announce a regime-specific set of features that "are not yet authorized for `` and must be disabled", and then configure the engine identically.

Two things are the same across all three branches:

* **The message.** The 13 printed bullets are byte-identical for `FEDRAMP_HIGH`, `IL4` and `IL5`; only the regime name in the lead sentence changes.
* **What is applied.** `configure_gemini_enterprise_for_fedramp_high` (`:1526`), `configure_gemini_enterprise_for_il4` (`:1642`) and `configure_gemini_enterprise_for_il5` (`:1754`) each load the same file and send its map unchanged:

```python
yaml_path = os.path.join(script_dir, 'engine_features.yaml')
with open(yaml_path, 'r') as f:
engine_features = yaml.safe_load(f)
...
engine_patch_body = { "features": engine_features.get('features'), ... }
```

There is one `engine_features.yaml` in the package, and it carries no regime dimension. So the engine's feature posture — including the four `disable-*` keys — is identical whichever regime the operator picks.

The **assistant** PATCH in the same functions *does* diverge by regime (FedRAMP High's `updateMask` includes `customerPolicy`; IL5's does not), which shows per-regime behavior is intended somewhere. That is what makes the identical engine feature set look unintended rather than deliberate.

## Environment and Deployment Context
* **Stellar Engine Version/Commit:** `v3.0.0` (`f64ce6cd`).
* **Deployment Type:**
* [ ] US Region Restricted (e.g., Access Policy constraint)
* [ ] FedRAMP Medium
* [x] FedRAMP High
* [ ] FedRAMP Moderate
* [x] DoD IL4
* [x] DoD IL5
* [ ] Stand-alone / Custom
* **FAST Stage (if applicable):
* [ ] Stage 0 (Bootstrap)
* [ ] Stage 1 (Resource Management)
* [ ] Stage 2 (Networking)
* [ ] Stage 3 (Security)

## Steps to Reproduce
1. Run `gem4gov app update-compliance --project-id --engine-id --compliance-regime FEDRAMP_HIGH`.
2. Run the same command against a second engine with `--compliance-regime IL5`.
3. `GET` both engines and diff their `features` maps.

## Expected Behavior
Either each regime applies the feature set its own on-screen list describes, or — if the three regimes genuinely share one engine feature set — the tool says so once instead of naming a regime it did not act on.

## Actual Behavior
The `features` maps are identical. Three regime choices produce one posture, announced three different ways.

## Relevant Logs and Errors
None. Both runs report success.

## Additional Context
The practical impact is that an operator deploying at IL5 is told a specific set of features is being disabled *for IL5*, and has no way to tell from the tool that the set applied is the FedRAMP High one.

If the sets should differ, this is a missing per-regime capability. If they should not, the messaging asserts a determination the code never makes. Either way the tool's output and its behavior disagree, and an auditor reading the transcript would conclude something the deployment cannot evidence.

Start with gem4gov app update-compliance and the onboarding flow, then inspect configure_gemini_enterprise_for_fedramp_high, configure_gemini_enterprise_for_il4, configure_gemini_enterprise_for_il5, and engine_features.yaml. Reproduce the FEDRAMP_HIGH and IL5 commands and compare the returned features maps. Done means the applied feature posture and the regime-specific message agree, whether the regimes receive distinct sets or one shared set is explicitly described.

Written by the indexing model from the issue text.