Sharp-move dedup window violates idempotency under same-minute reruns

Opus

Sharp-move dedup window violates idempotency under same-minute reruns

• skills/price-threshold-alert/SKILL.md:156-162
• skills/price-threshold-alert/SKILL.md:270-271

The constraint promises idempotency under same-minute reruns, but the sharp-move step writes `last_alerts.sharp_move = NOW` every time it fires. If the run is re-executed within the same minute with the same price input, the first run sets last_alerts.sharp_move to T0; the second run sees that timestamp within 4h and dedups. That is consistent. However, the ATH gate (Step 4) only updates `state.ath.announced_at` for the baseline case; for a real ATH it updates `observed_at` but does not specify updating `announced_at`/`last_alerts.ath`. The spec says "Notify only if the last ath alert was >4h ago" but never tells the implementer to set `last_alerts.ath = NOW` on a real ATH notification. Consequently, a re-run with the same higher price would: (a) see CURRENT_PRICE not strictly greater than the just-updated `ath.price_usd`, so `new_ath=false` — actually safe. But the missing `last_alerts.ath = NOW` write means if a later run sees an even higher price within 4h, the dedup check has stale data and the alert fires again, which is fine — but the documented dedup clock is never advanced for ATH alerts in the spec text, making the 4h dedup unreachable in practice. This is a spec/contract gap.