fix(apps): refuse a compose edit that shrinks or drops a volume (#292)

[v0l]

Closes #292.

PATCH /api/admin/v1/apps/{id} now refuses a compose that lowers a volume's size or drops a (service, volume name) pair the stored compose declares (lnvps_compose/src/lib.rs:751, wired at lnvps_api_admin/src/admin/apps.rs:406). Comparison is in bytes, so 5Gi -> 5120Mi passes.

Removal and rename were in the "say what you find" part of the issue — both are as unrecoverable as the shrink, so both are refused:

• Shrink — Kubernetes expands PVCs only; the next reconcile is a permanent 422 for every existing deployment.
• Remove — server-side apply cannot prune an object we merely stop applying, so the PVC survives with the customer's data in it, unmounted and no longer counted against the app's storage.
• Rename — a remove plus an add: the pod comes back on a new empty PVC and the old one keeps the data.

Create is unaffected (no stored row to compare against), and so is the operator: this is an authoring rule like the volumes:/user: check from #277, so a row stored before it keeps reconciling. A stored compose that no longer parses is skipped rather than fatal, so an admin can still repair a broken row.

Tests: lnvps_compose unit test for the six shapes, and lnvps_e2e test_admin_app_compose_volume_may_not_shrink over HTTP (lnvps_e2e/src/admin_api.rs:1182). Full e2e suite 159 pass locally; cargo test --workspace clean.

Docs: API_CHANGELOG.md, docs/managed-app-examples.md.

Channel: lnvps (f5894ea9-44c7-56fb-bd9b-6e3e671e4bc1)