Description
## Problem
The body discovery / eligibility check (hydracluster GET /api/v1/nodes/eligible-bodies) selects bodies that are online, have the hydrabody role, and are in the right district. It does NOT check whether the body has the requested experience registered in Sunshine. This means a body can appear eligible, Moonlight connects, and only then discovers the experience app is missing — by which point the stream has already failed on screen.
## Observed on 2026-05-14
cheeky-cactus-86 requested rupelmonde-castle-viewer. Body discovery selected cosmic-pretzel-98 (correct district, online, hydrabody role). Moonlight paired and connected to Sunshine. Sunshine app list did not contain rupelmonde-castle-viewer (hydrabody had deregistered it due to a failed download loop). Moonlight exited: 'Failed to find application rupelmonde-castle-viewer'.
The body accepted the stream initiation despite not being able to serve the requested experience.
## Root cause
hydrabody reports to hydracluster via POST /api/v1/body/status but does not include which experiences are currently registered in Sunshine. Eligibility check therefore cannot filter on experience availability.
## Proposed fix
Two-part:
1. hydrabody includes installed_experiences: ["mercator-talks", "rupelmonde-castle-viewer"] in its body status heartbeat (the list of experiences currently registered in Sunshine with working hooks).
2. hydracluster eligibility endpoint accepts optional ?experience=<name> query parameter. When provided, only returns bodies where that experience appears in their last reported installed_experiences.
This ensures the discovery layer only routes to bodies that can actually serve the requested experience. If no body in a district has the experience registered, the head gets an empty eligible-bodies list and can show a 'not available' message before attempting to connect.
## Secondary fix (hydrabody side)
hydrabody should not deregister a Sunshine app for an experience whose exe already exists on disk at the expected path. If exe_path from the experience library resolves to an existing file, the experience should be considered installed and registered regardless of whether the download record exists in experiences.yaml. This prevents the availability/provisioning split that caused this incident.