Actualizar la salud de un número

POST /devices/{device}/health/refresh — triggers MetaHealthStatusService::refreshAndPersist() (at most ONE live Meta call, subject to D7's 60s cooldown and per-device Cache::lock) and returns the SAME shape as show(), plus refresh_outcome

Escritura · requiere el permiso accounts:write.

refresh_outcome (security-auditor finding — Increment 4 plan review, "the endpoint must tell the truth about what happened"): refreshAndPersist() can return the pre-existing snapshot for THREE different reasons — it genuinely refreshed, it bounced off the 60s cooldown, or it couldn't acquire the per-device lock (another refresh — the scheduled command, another tab, another agent — is already in flight for this exact device) — and from the HTTP response alone those three are indistinguishable. A 200 with stale data and no signal after the user clicks "Actualizar ahora" is a silent lie.

Resolution: compare last_fetched_at BEFORE and AFTER the call. refreshAndPersist() ALWAYS advances last_fetched_at when it genuinely attempts Meta — success or failure alike (design.md D7: it's attempt metadata, not a health field) — and NEVER advances it on either bounce. So:

• unchanged (or still null) → 'not_refreshed_yet' — covers BOTH the cooldown bounce and the lock-contention bounce; the frontend doesn't need to tell them apart to render "esperá un momento", and collapsing them avoids inventing a distinction the service's own public contract (refreshAndPersist(): DeviceHealthStatus, Increment 1, already covered by 40+ tests) doesn't expose without a breaking change.
• advanced → 'refreshed' — a live call was actually dispatched, regardless of whether Meta answered with success or an error (that distinction is already visible via health.state/stale).