feat: serve event firmware metadata at GET resource/eventFirmware

[jamesarich]

Adds GET resource/eventFirmware, the API endpoint anticipated by the event-firmware contract in Meshtastic-Android#5920.

That PR defined the JSON Schema and a bundled seed asset but deliberately left the upstream endpoint as a follow-up. This is that follow-up, plus the first hosted event icon.

Endpoints

• GET resource/eventFirmware — returns the {version, generatedAt, source, editions[]} envelope (mirroring deviceLinks). The seed JSON is already in response shape, so it is served verbatim — no transformation.
• GET resource/eventFirmware/hamvention.png — serves the Hamvention event icon (PNG).

What this does

• data/eventFirmware.json — seed metadata for the 4 current editions (Hamvention, Open Sauce, DEFCON, Burning Man). This repo becomes the source of truth the app will sync from.
• src/lib/eventFirmware.ts — reads + parses the file once per process.
• src/routes/eventFirmware.ts — serves the metadata, 502 on read failure.
• static/eventFirmware/hamvention.png + src/routes/eventFirmwareIcon.ts — vendors and serves the Hamvention icon. Renamed from Android's img_event_hamvention.png to drop the drawable-resource prefix; grouped under eventFirmware/ and served under resource/ (same data/ → resource/* indirection as deviceLinks).

Seed data — verified against official sources

All fields were fact-checked via web search; several seed values were corrected:

Field	Result
eventStart/eventEnd	All 4 verified. Open Sauce start corrected 07-18 → 07-17 (official festival is July 17–19; the 17th is Industry Day).
location / timeZone / links	All 4 correct.
accentColor	Hamvention #005DAA → #BF1E2E (was blue; official logo is a red Ohio badge — sampled from the logo PNG). DEFCON #C0392B → #0D294A (was a Flat-UI placeholder; DC34 style-guide primary). Burning Man #E8552D → #EC8819 (official Carrot Orange). Open Sauce #E94F1D kept — its logo is monochrome, no brand color exists.
iconUrl	Hamvention now points at the hosted icon above. The other three stay null — they have no bundled art in the app (EventEdition.kt: iconRes = null), and their official logos are unusable to vendor (Burning Man's trademark policy forbids promotional use; DEFCON/Open Sauce publish no openly-licensed assets). Original Meshtastic art is the path forward there, matching the Hamvention precedent.

Not in this PR (deferred, matching the Android PR's staging)

• Schema validation in CI.
• A real upstream data sync — generatedAt/source come from the committed snapshot.
• Icons for the other three editions (pending original art).

Notes

• iconUrl hardcodes https://api.meshtastic.org, consistent with how deviceLinks hardcodes msh.to URLs.
• The icon route is a single fixed path for the one icon hosted today; generalize to a slug param when more editions ship art (marked with a ponytail: comment).

Testing

• biome clean; tsc clean (one pre-existing unrelated error in yieldFromEvent.ts).
• Metadata lib smoke-tested to parse and return all 4 editions; icon file verified to resolve as a valid PNG via the route's path resolution. Full server not booted (requires Redis/MQTT).

🤖 Generated with Claude Code

[jamesarich]

@thebentern noted that we have additional metadata in the flasher that could be housed here as well

[jamesarich]

Follow-up scoping: moving flasher event config into this API

Per @thebentern's suggestion, looked at moving event-manifest config out of web-flasher and into this API. Summary for tracking — assessment only, nothing built here.

What's movable

The flasher hardcodes per-event EventModeConfig objects in types/resources.ts and selects the active one via export const eventMode = …. Every event switch is a code edit + redeploy. The flasher already calls api.meshtastic.org for hardware/firmware lists, so serving this config from the API is a natural fit and removes the redeploy-per-event friction.

Per-event payload that would move: domain, enabled/active selection, eventName, eventTag, pathPrefix (builds the firmware URL event/{pathPrefix}/firmware-{ver}), and firmware (id, title, zip_url, a long markdown release_notes).

Recommendation: a separate endpoint, not an extension of eventFirmware

The two "event" datasets look related but are different concerns:

	eventFirmware (this PR, Android contract)	flasher eventMode
Purpose	in-app display / theming	which firmware to flash + flasher branding
Fields	edition, displayName, welcomeMessage, dates, tz, location, iconUrl, accentColor, links	domain, pathPrefix, firmware zip_url, release_notes, eventTag
Event set	Hamvention, Open Sauce, DEFCON, Burning Man	Hamcation, Hamvention
Contract	frozen JSON Schema, additionalProperties: false	none yet

Near-zero field overlap, the event lists don't match (Hamcation isn't a FirmwareEdition enum), and overloading the published Android schema couples two unrelated consumers. A parallel resource/eventFlasher (name TBD) can reuse the exact committed-file-served-verbatim pattern this PR introduces.

Flags before building

1. eventTag is a code smell, not just data. LogoHeader.vue has hardcoded per-tag markup (v-else-if eventTag === 'Hamvention'). Moving config to the API won't remove the per-event branding deploy unless logos are also data-driven (icon URLs — the direction this PR started for the Android side).
2. release_notes are large markdown blocks — decide inline vs. separate fetch.
3. Firmware binaries stay at meshtastic.github.io/event/{pathPrefix}/…; the API would only carry the pointer.
4. Two-PR rollout: API endpoint first, then a flasher PR to fetch instead of hardcode (keeping the static config as fallback).

Bottom line

Worth doing — kills the redeploy-per-event friction. Cleanest as a new resource/eventFlasher endpoint mirroring deviceLinks, not folded into the Android eventFirmware contract. The one thing data-in-API won't fix by itself is the hardcoded per-event branding markup in the flasher.

cc @thebentern — does a separate endpoint sound right, and should the flasher migration be its own follow-up?