Partition manager: ANALYZE a just-created partition directly instead of relying on the throttled parent recurse

Problem

Gitlab::Database::Partitioning::PartitionManager's post-rotation ANALYZE is throttled by last_analyzed_at_within_interval?, which reads pg_stat_get_last_analyze_time from the oldest partition as a table-level proxy (partition_manager.rb#L209-L221).

Because the throttle keys off the oldest partition, a freshly-rotated leaf partition can sit with no planner statistics (reltuples = -1) for up to the full analyze_interval before the throttled parent-recurse ANALYZE next fires. A statless partition is exactly what let the planner pick a 483M-row parallel sequential scan in INC-13566.

Setting a tighter analyze_interval (as !252297 does for Security::Finding with 1.day) only shrinks this window; it does not close it. The window is bounded by the interval, not by partition creation.

Proposal

When the partition manager creates a new leaf partition, ANALYZE that partition directly (bypassing the interval throttle), so a newly-rotated partition never serves queries with zero statistics. Options to evaluate:

• Run a targeted ANALYZE <new_partition> on the just-created leaf in the creation path, independent of last_analyzed_at_within_interval?.
• Or have the throttle consider the newest partition's stats (not only the oldest) so a statless new leaf forces an ANALYZE.

Either closes the post-rotation gap at its source rather than relying on a short interval to paper over it.

Context / related

• Immediate corrective action (interval override): !252297 (#624174, INC-13566)
• Systemic default-interval work: #624175
• The 1.day override on Security::Finding is the mitigation; this issue is the proper fix for the residual post-rotation window called out in !252297's review by @reza-marandi.