Description
Today open issues live in `hydraissue` (issues.experiencenet.com) and nodes live in `hydracluster` (`nodes.yaml`). When operating a kiosk or body, there is no way to see "what open issues exist for this specific machine" without manually searching issue titles.
Proposal: surface per-node open issues in the hydracluster admin UI's node detail view.
## Possible designs
**A. Read-side join in hydracluster** (recommended)
- hydracluster admin UI calls `hydraissue` `GET /api/v1/issues?q=<node-name>+OR+<node-id>` (or a structured field) when rendering a node's page.
- Display matching open issues as a small list with title + status + link.
- No data model change in hydraissue; relies on hostname/node-id appearing in the issue title or description, which is already convention.
**B. First-class node field on issues**
- Add a `nodes []string` field to `Issue` in hydraissue's store.
- New endpoint `GET /api/v1/issues?node=<id>` returns issues tagged with that node.
- hydraissue admin UI gets a node-id selector when filing/editing.
- hydracluster's node page calls this filtered endpoint.
**C. Pure convention** (cheap)
- Standardise the issue title prefix (e.g. `[node-adf19775]` or `[turbo-pancake-76]`) and rely on text search.
- hydracluster admin UI links out to `issues.experiencenet.com/?q=<node-name>` rather than embedding results.
- No code changes to hydraissue; only convention + a link.
## Recommendation
Start with **A** for read-side surfacing (low cost, immediate value), then move to **B** if the volume of node-tagged issues grows enough to warrant structured filtering.
## Why now
We just filed two node-specific issues (#122 catalog refactor scoped at cheeky-cactus, and the cosmic-pretzel firewall issue we are about to file). Without a linkage view, the next operator looking at cosmic-pretzel-98 in hydracluster has no idea there is an outstanding firewall issue against it.