Reach every recording a fault kept, not just the newest

[mfaferek93]

Summary

ros2_medkit#620 lets one fault hold several black-box recordings instead of overwriting on every re-confirmation. This is the web UI side of that: the extra recordings have to be visible, distinguishable and downloadable, and three existing behaviours got in the way.

Verified in a browser against a real gateway holding two real bags produced by the real capture pipeline. Every fix below has a spec that fails without it - all three specs go red when the source changes are reverted.

What was wrong

• The fault detail was fetched once per fault and cached forever. A recording written while the page was open stayed invisible until the component remounted, which is exactly the recording a technician watching a machine fault again is waiting for. It now refetches on expand; the previous entry stays rendered meanwhile, so re-expanding does not flicker.
• The dashboard keyed that cache by fault code alone. It lists faults from every entity at once, and a fault code is only unique within one entity, so two apps both reporting LIDAR_RANGE_INVALID rendered each other's environment data - download buttons pointing at another entity's recordings. The key now includes the entity. This was reachable before #620; several recordings per fault only make it easier to hit.
• The download buttons had no accessible name at all. The icon variant renders no text, so a fault with N recordings became N nameless identical buttons: unusable with a screen reader, ambiguous with a mouse. Each is now named after the recording it fetches.
• The saved file lost its extension. The filename came from the descriptor's display label (<id> recording <timestamp>) rather than from the gateway's Content-Disposition, so a bag landed on disk with no .mcap and neither the OS nor ros2 bag play could open it without a rename. The server is the only party that knows the storage format, so its name is the one to use; this also drops a listing round-trip per download.

Testing

• e2e/rosbag-recordings.spec.ts - three specs in a real browser: the detail shows every recording with distinct names, each downloads as its own bag with a real extension, and re-expanding refetches. Reverting the source changes turns all three red.
• e2e/docker-compose.rosbag.yml - a stack with a fault manager, which the scripts stack does not run, plus a seed that confirms, acknowledges and re-confirms one fault so it ends up owning two bags.
• src/lib/store-download.test.ts - the Content-Disposition parser, including the RFC 5987 form and the empty-filename case that an earlier draft got wrong.
• Full suite: 625 unit tests, lint and typecheck clean.

Ordering

• Based on Add a Playwright end-to-end harness with a containerised gateway #91 to reuse its Playwright harness rather than stand up a second one. Nothing in that PR is modified here.
• The specs assert the recording-id contract from ros2_medkit#620, which is newer than any published gateway tag. They skip with a named reason until an image carrying it exists; point E2E_ROSBAG_GATEWAY_IMAGE at a local build to run them now.

[bburda]

Three things outside this diff that I think also need a change:

• CONTRIBUTING.md still describes one stack. The new stack, the separate compose project name, the image override and the seeding step are not written down anywhere, so nobody can reproduce the run from the repo. It also tells developers to move the gateway to port 8081 when 8080 is taken, and that is the port the new stack takes by default.
• The CI workflow only starts the old stack, so npm run test:e2e runs the new project and reports three skips. They show up as skipped, but nothing fails. Skipping is the right behaviour until the gateway change lands, but could you wire the stack into CI in the same change that pins the published image, so these specs do not stay dormant after that?
• Nothing that runs in CI covers the two behaviour fixes (the entity aware cache key, the refetch on expand). There is no test file for FaultsDashboard or FaultsPanel. I wrote three vitest cases while reading this and all three reproduce the problems flagged inline, so they are cheap to cover.