Instance-level equipment types: let the admin add gym kit the catalogue doesn't have

[temperatio]

The problem

The equipment filter works from a fixed list of catalogue types (barbell, dumbbell, cable, …). A
real gym or home setup often has kit that isn't on it: a dip station, a landmine, parallettes, a
sled, a specific machine. Today there is no way to say "we have this" or "this exercise needs
that", so:

• a custom exercise that uses such kit can only be tagged with the closest catalogue type, and
  the equipment filter shows or hides it for the wrong reason;
• a catalogue exercise that in practice needs something extra (a bench and a landmine, say)
  shows up for every profile that has the catalogue equipment, even if the gym has no landmine.

What I built (in a fork, working on my own instance)

Equipment types per instance, curated by the admin.

• The admin adds, renames and deletes types in the admin dashboard. Each gets a stable x- id,
  so renaming never touches profiles or exercises. Catalogue types can't be renamed or deleted,
  and a new name can't collide with any catalogue type in any language the app ships.
• Added types appear next to the catalogue ones everywhere equipment is picked: equipment
  profiles, the custom-exercise form, the library filter, the workout tooltips.
• The admin can say that a catalogue exercise also needs one or more added types. With the
  equipment filter on, that exercise only shows for profiles that have them. The catalogue
  itself isn't modified; this is a per-instance overlay.
• Deleting a type also removes it from every exercise's needs. Profiles and custom exercises that
  still reference it treat it as nothing to filter on, so nothing breaks.

Users propose, the admin decides.

• A signed-in user who's missing something sends a proposal (name + optional note) from
  Settings → Equipment. The admin can approve it (optionally correcting the name), merge it into
  an existing type, or reject it. The user sees the status of their proposals. At most 10
  pending per user.

A name per language.

• Users of the same instance can have different app languages, so a type can carry a name in
  each of the app's languages. The admin's editor shows how many languages are covered (e.g.
  "Languages: 5/19") and lists the missing ones first. Each user sees the name in their
  language, falling back to the main name. When the admin corrects a proposal's name, the
  proposer's original wording is kept as the name in their language.

Without a server. A guest, or the phone app in local mode, gets the same editor for its
own device-only list. That list is never uploaded and is kept apart from the server's.

How it's built

• API: one new module (api/equipment.js) and a separate DATA_DIR/equipment.json (plain
  catalogue data, 0644, kept apart from db.json on purpose), written with atomicWrite.
  Routes: GET /api/equipment for every signed-in user, plus GET/POST /api/equipment/proposals and four /api/admin/equipment/* routes behind requireAdmin. Admin
  actions go to audit.log. Documented in openapi.yaml.
• Frontend: the instance list lives outside S, because it's the instance's, not the user's,
  and must not be merged between devices. It's cached in localStorage (and mirrored to a file
  on the phone, like the state) so it works offline. It refreshes at sign-in and when the app
  comes back, at most once a minute.
• No new dependencies. Tests for the store, the routes, the client cache and the filtering
  helpers. New strings are in all 18 locales and check-locales passes. The admin card is in
  English, like the rest of the admin dashboard.
• Compatibility: an older client or an older server simply doesn't see added types; nothing
  is lost.

Questions before I open a PR

1. Is this something you'd want in openGym, or would you rather keep the equipment list
   catalogue-only?
2. Is a separate equipment.json with its own routes the right shape, or would you prefer it
   somewhere else?
3. Is the proposal flow worth having, or should it be admin-only to keep it smaller? I could
   split it into two PRs (types + needs first, proposals and per-language names after).

Happy to adapt the design to whatever fits the project best.