Deploy and unregister --rm-data silently destroy another instance's ExApp container and volume when two Nextclouds share one Docker daemon

We lost the data volume of a working ExApp because a second Nextcloud instance on the same host uninstalled its own copy of the same app.

Setup: two Nextcloud instances (a real one and a throwaway test instance), each with its own HaRP, both pointing at the same Docker daemon. Container and volume names are built from the app id alone (nc_app_<appid>, nc_app_<appid>_data), so both instances resolved to the same container and the same volume.

Two things happened, and I think both deserve a look:

1. Deploying the app on instance B force-removed the running container of instance A and recreated it with B's APP_SECRET and NEXTCLOUD_URL (DockerActions.php:138 on the HaRP path, :81-88 on the classic one). A's app was broken from that moment, without any warning.
2. occ app_api:app:unregister <appid> --rm-data on B then deleted the shared volume. For us that was a search index over 50,000 files, roughly 19 hours of rebuild. Docker's own "volume is in use" protection could not help because step 1 had already removed the container that held it.

None of the removal paths checks who created the container or volume: the occ command (Unregister.php:106 and :135-139), the admin UI (ExAppsPageController.php:494-500), and removing a deploy daemon (AppAPIService.php:806/809), which deletes volumes without any flag at all.

I know about #523 and this is deliberately not another naming ticket: even with an instance prefix in place, existing volumes stay unprefixed and the removal paths still delete blindly. It is also not the multitenancy request from nextcloud/HaRP#49, rather the opposite: we do not want to share a container between instances, we want two independent deployments to stop destroying each other.

A fix that would have saved us, and that looks backportable: set labels on container and volume at create time (for example nextcloud.appapi.instance_id) and make the removal paths refuse when the label points to a different instance. Right now the Docker path sets no labels at all, while the Kubernetes path already sets app.kubernetes.io/instance from instance_id (haproxy_agent.py:2374), so the pattern exists in the codebase.

Observed with Nextcloud 34.0.3, AppAPI with HaRP 0.4.5, Docker on Ubuntu (arm64). Happy to share the full logs with timestamps.

Start with DockerActions.php:138 and :81-88, then inspect the removal paths in Unregister.php:106 and :135-139, ExAppsPageController.php:494-500, and AppAPIService.php:806/809. Compare these paths with the instance label handling in haproxy_agent.py:2374. Done means Docker containers and volumes carry an instance identity and removal refuses to delete resources belonging to another instance while preserving same-instance cleanup.