Database File Growth's rise arm re-fires every cooldown against the same hourly observation: up to twelve cards per growth event — #3579's mechanism, one condition over #3636

Summary

The Database File Growth alert's rise arm has the mechanism #3579 just fixed for Forced Plan Failing, at a worse ratio: it evaluates a stored between-collections delta on every ~30-second alert pass and re-fires on every cooldown expiry (5 minutes) for as long as the same observation stands — and its feeding collector, database_size_stats, runs hourly. One growth event can produce up to twelve cards before the next collection replaces the observation. The level arm re-fires by design and is not this.

Mechanism (VERIFIED at source by the #3579 census)

AlertEngine's file-growth check reads DatabaseFileGrowthInfo rows from the adapter; the adapter's CTE carries c.collection_time but never projects it, so the engine has no observation identity to remember. Same shape as #3579's adapter/engine pair before #3628; same fix: the adapter returns the observation's collection_time (both SKUs' SQL + the info record), the engine keeps the last-alerted stamp per (server, database, file) beside the arm's existing state and declines to re-fire the same stamp regardless of cooldown. A file that keeps growing across successive hourly collections still fires per collection; recovery unchanged.

Not a two-line rider on #3628 — it touches both SKUs' SQL, the info type, and the engine's per-key state — so it is its own lane of #3628's size. The #3579 census cleared every other condition: Poison Wait already guards on NewestCollectionTime (#2704); blocking/deadlocks/CPU/LRQ/tempdb/disk/PVS/jobs/database-state are level, gated, or watermark shapes, not this one.

Related: #3579, #3628.