[Board] Boards are tombstoned and telemetry keys on the Board id

[KacperKozak]

Deleting a Board now leaves a tombstone instead of removing its row, and every telemetry table keys on board_id rather than the mutable BLE identifier. Ride History keeps a stable, resolvable Board identity, and renaming a Board relabels its whole history.

Note

Risk: Medium — changes deletion semantics and rewrites five telemetry tables on upgrade.
Complexity: Medium — small runtime surface, but the read/write split and the identifier resolution have to hold identically in Room and GRDB.
DB: Schema + data — additive boards.deleted_at (41), then a rebuild of all five telemetry tables onto board_id (42).

Tasks

• [Telemetry] Reconsider device_name denormalization on telemetry tables #274
• [Board] Verify Board tombstoning on dev #428

Description

The BLE identifier was never an identity. It is nullable, it moves when a Board is re-linked to a different peripheral, and one address can be claimed by two Boards, so two readers resolving the same address were free to disagree — which is how a ride could end up with its frames under one Board and its buckets under another. The denormalized device_name existed to paper over that and over Board deletion, but it froze the label at capture time and could never answer "which rides came from this Board".

Two decisions fix it together, which is why they land in one PR: a Board's row has to survive deletion before telemetry can safely point at it.

Boards are tombstoned (ADR 0027). Deleting a Board stamps boards.deleted_at. Board-owned configuration — settings, warnings, Alert Rules, Last Known Board Config Values — is still hard-deleted; telemetry and Tune Profiles are untouched, as before. getBoards() filters tombstones so they leave every Rider-facing list, while getBoard(id) deliberately resolves them, because history still has to name a deleted Board. Paths that act on a Board rather than describe one refuse a tombstone. Deletion is terminal: an ordinary upsert carries an existing tombstone forward instead of clearing it.

Telemetry keys on the Board id (ADR 0028). Frames, minute buckets, markers, diagnostic events and metric exclusion ranges all carry board_id and drop both device_id and device_name. Names resolve from boards on read. The bucket primary key moves to (bucket_start_ms, board_id). The boardId -> bleId translation that markers, events and ranges needed is deleted, along with the session-boundary bug it caused.

The migration resolves each BLE identifier to a Board exactly once, into a shared scratch map every rebuild reads, so no two tables can pick different claimants of a duplicated address. Where an address is ambiguous the pick is arbitrary but stable (lowest boards.id) — for rows predating the migration no evidence of the real Board exists. Rows that resolve to no Board at all mint one tombstoned Board per unresolved identifier, named from that row's historical device_name, so orphaned history keeps a label and stays joinable rather than becoming unowned.

Both slices are extracted from the long-running Ride History backup branch (#276), where they were implemented and tested first, and rebased onto current dev: renumbered onto schema 41 and 42 (the branch used 37-39, which dev has since spent on VESC fault evidence), stripped of the backup-only sync cursor machinery, and extended to cover RideHistoryRepository, which landed on dev after that branch forked. Every code change here comes from #276, including the board_warnings cascade that the re-implementation in the closed #435 was missing.

ADR 0027 is the exception, and deliberately so. #276 argues the decision through the server's Board-owned foreign keys, Sync Batches and Delete Actions — none of which exists on dev — so this PR carries the app-scoped wording, which states the same decision and defers the server half to #276.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}