…y#579)

When a primary without persistence restarts empty, replicas full-resync
and silently wipe their own data. Add two state-transition detectors to
the anomaly poller: Rule A fires when a primary comes back empty with
restart evidence (replid change / uptime reset / offset regression), and
Rule B fires when a replica's dataset collapses after a replid change.
Both emit a CRITICAL dataset_keys anomaly, dispatch a new Pro-tier
data.loss.detected webhook, and surface a remediation-runbook banner on
the anomaly dashboard.

- getLatencyStatsHistory kept the OLDEST rows within the 10k cap (ORDER BY
  captured_at ASC + LIMIT), so busy instances dropped the newest samples the
  regression guard depends on for freshness/version/consecutive logic. Now
  return the most-recent `limit` rows (inner DESC + LIMIT, then ascending) in
  the sqlite/postgres/memory adapters. (High)
- Sustained-degradation rule was only suppressed while the upgrade window was
  UNFIRED, so after the one-shot upgrade event fired it could re-report the same
  post-upgrade regression as a second anomaly/webhook. Suppress sustained for
  the entire open upgrade window; it resumes only after the 24h window expires.
  (Medium)

Adds tests: cap keeps newest samples; sustained does not re-fire after an
upgrade event within the window.

- Empty upgrade window no longer blocks sustained detection: suppress the
  sustained rule only for commands the open upgrade window actually owns (has a
  baseline for), instead of gating on the window globally. A version change
  where no command had enough pre-change samples now leaves sustained active
  rather than silencing it for up to 24h. Still prevents the one-shot upgrade
  event from being re-reported via sustained. (Medium)
- AnomalyDashboard formatValue now renders command_p99 in ms/µs (values are
  stored in microseconds) instead of the generic K/M scale. (Low)

Adds a test that sustained still fires when a version change opens an
upgrade window with no baselines.

- Duplicate webhooks per regression (Medium): the anomaly->webhook integration
  poller fired a generic anomaly.detected for every saved command_p99 event, on
  top of the dedicated latency.regression.detected, producing two Pro webhooks
  for one incident. Skip command_p99 in the generic dispatcher.
- Missing anomaly instance fields (Low): populate sourceHost/sourcePort on the
  saved command_p99 anomaly (from the connection context), consistent with the
  other anomaly producers.
- Stale summary after section loss (Low): the latencystats poller returned early
  when the INFO section disappeared, leaving the in-memory snapshot intact so
  GET /metrics/latencystats/summary served outdated percentiles. Clear the
  snapshot when the section is absent.

Adds tests for each: command_p99 skipped by the generic dispatcher, the saved
event carries instance metadata, and the snapshot is cleared on section loss.

…stinct samples

Addresses two review comments on #304.

1. Version gating (regression-detector.ts:~184). The upgrade window opened on any
   version-string change, so a patch/build flip (7.4.0 -> 7.4.1) or a downgrade
   reached sustained.clear() — dropping every command's 30-min cooldown and
   consecutive streaks — and got labeled upgrade_regression. Now only a
   major-version *increase* opens a window (parseMajorVersion already existed);
   other changes just update lastVersion, leaving sustained state intact.

2. Consecutive counting (regression-detector.ts:~244, both rules). The streak
   advanced once per poll tick, keyed only on freshness (<150s), so a repeated
   sample (skipped poll or a failed storage write re-returning the prior row)
   inflated the count and could fire before 5 genuinely-distinct samples. Track
   the last-counted capturedAt per command and only advance on a strictly newer
   sample; a stale/non-degraded newer sample still resets.

Tests: repeated samples don't fire early (needs 5 distinct); a patch bump opens
no upgrade window while a major bump still fires upgrade_regression.

The banner poll passed only metricType and relied on the events endpoint, but
GET /anomaly/events applies a default 24h startTime when none is given. An
unresolved data-loss incident older than 24h was filtered out, so the banner
could go silent while storage still held an open incident.

Add an explicit `activeOnly` feed end to end:
- getRecentAnomalies(activeOnly) queries durable storage with resolved:false and
  no startTime floor (the in-memory cache is capped and lost on restart, so an
  old open incident must come from storage). AnomalyQueryOptions.resolved is
  already supported by every adapter (postgres has a partial unresolved index).
- Controller exposes ?activeOnly=true, skips the 24h default for it, and switches
  the default from `||` to `??` so an explicit startTime=0 is honored.
- API client forwards activeOnly; the data-loss banner poll sets it.

Adds service tests: activeOnly reads storage with resolved:false and no
startTime, and bypasses the in-memory cache branch.

…unpersisted incidents

Addresses two bugbot findings on #302.

- resolveGroup marked members resolved in memory and returned true even when
  storage.resolveAnomaly threw/failed, so a client could dismiss a group while
  storage-backed polls still returned members unresolved. Now mirror
  resolveAnomaly: only flip the cached copy for durably-resolved members and
  return true only when every member persisted.

- The activeOnly (data-loss banner) feed read durable storage only, so an
  incident whose saveAnomalyEvent failed — while the Pro webhook still fired —
  had no matching banner until a later poll persisted it. The feed now unions
  storage with in-memory unresolved events (dedup by id, storage wins; same
  filters), so a dispatched incident is always visible.

Tests: resolveGroup success/partial-failure/no-row-updated; activeOnly union,
dedupe, and resolved-exclusion.

…es closed members

Bugbot follow-up on #302. resolveAnomaly returned false for an already-resolved
row (WHERE resolved = false matched nothing), indistinguishable from a missing
row. resolveGroup then reported { success: false } when any member was already
resolved — via a retry, a partial resolve, or resolving one anomaly through the
data-loss banner before the group — even though every event was closed in storage.

resolveAnomaly is now idempotent across all three adapters: it returns true when
the anomaly is resolved (newly or already), and false only when no anomaly with
that id exists. resolveGroup's all-persisted check is now correct as-is.

Adds a describe.each (memory + sqlite) test: first resolve and re-resolve both
return true; an unknown id returns false.

…lure

Two Bugbot findings:

1. Patch bump shrinks upgrade baseline. The pre-upgrade baseline included only
   samples whose serverVersion exactly equalled fromVersion. After a patch/minor
   bump just before a major upgrade (8.1.0 -> 8.1.1) fromVersion is the patch
   label, so hours of 8.1.0 samples in the 6h lookback were dropped, leaving too
   few rows or a skewed median. Match the pre-upgrade MAJOR line instead.

2. Detector fires before persistence. evaluate() latches the one-shot upgrade
   guard and per-command sustained cooldown when it returns a finding, but the
   service persisted afterwards and swallowed save errors while still dispatching
   the webhook. A transient saveAnomalyEvent failure therefore dropped the record
   yet suppressed re-emit (and still notified). Add detector.revert(finding),
   which the service calls only on a save failure to re-arm the finding for the
   next poll; the webhook now fires only after a durable save.

Tests: baseline built from the whole pre-upgrade major line; revert re-fires the
upgrade one-shot and sustained cooldown; the service does not notify on a failed
save and re-emits+persists+notifies once storage recovers.

…stalled

The revert() added for persistence-failure retries restored a sustained
finding's consecutive streak and cleared its cooldown but left lastCountedAt on
the sample that already fired. evaluateSustained's "count physical samples, not
poll ticks" guard then skipped the command until a NEWER latencystats row
existed, so a failed persist would not re-emit on the same stored sample —
unlike upgrade retries, whose fire loop is separate from that guard. Reset
lastCountedAt to -1 in the sustained revert branch so the unchanged sample is
re-counted and the finding re-emits on the next poll. Adds a repoll-based test
(same sample, no new row) that fails without the reset.

…sion-guard

# Conflicts:
#	proprietary/anomaly-detection/__tests__/anomaly.service.spec.ts
#	proprietary/anomaly-detection/anomaly.service.ts
#	proprietary/anomaly-detection/types.ts

…latency-regression-guard

# Conflicts:
#	proprietary/anomaly-detection/__tests__/anomaly.service.spec.ts
#	proprietary/anomaly-detection/anomaly.service.ts
#	proprietary/anomaly-detection/types.ts

… no rows

Two bugbot findings on #304.

- The P99 regression banner polled getAnomalyEvents with only
  metricType=command_p99, so the API's default 24h startTime hid unresolved
  command_p99 incidents older than a day — unlike the data-loss banner. Pass
  activeOnly:true so open incidents of any age reach the banner.

- MemoryAdapter.getLatencyStatsHistory used `options.limit ?? 10_000`, so a
  limit of 0 survived (0 is not nullish) and `slice(-0)` returned every row
  instead of none. Guard limit <= 0 to return [], matching SQL `LIMIT 0`.

Adds a describe.each (memory + sqlite) test that limit:0 returns no rows.

…sion-guard

# Conflicts:
#	apps/web/src/components/webhooks/WebhookForm.tsx
#	apps/web/src/pages/AnomalyDashboard.tsx
#	packages/shared/src/webhooks/types.ts
#	proprietary/anomaly-detection/__tests__/anomaly.service.spec.ts
#	proprietary/anomaly-detection/anomaly.service.ts
#	proprietary/anomaly-detection/types.ts
#	proprietary/webhook-pro/webhook-events-pro.service.ts