[fpv,alert_handler] Strengthen test to check saturation of a prim_count in alert_handler_esc_timer_fpv

Nobody has claimed this yet.

### Description

The `prim_count` in `alert_handler_esc_timer.sv` is instantiated without the ability to jump to a different value because `set_cnt_i` is driven with `EscCntDw'(1)`.

Inside `prim_count`, there are two assertions that say the count should saturate at the maximum value (`UpCntIncrStable_A` and `DnCntIncrStable_A`). The existing FPV testbench in `alert_handler_esc_timer_fpv.sv` can't actually see this happen! The problem is that the counter is 32 bits wide. The condition is unreachable in the tests because we bound the number of increments to 10. If you comment out this bound, Jasper will happily run forever as it counts to 2**32...

In #22797, I waived the cover property that comes from these assertions. We could consider strengthening things by bodging in something that would allow the count to jump, analogously to the `fpv_force` signal that is already in `prim_count.sv`.

Start with alert_handler_esc_timer.sv, alert_handler_esc_timer_fpv.sv, and prim_count.sv, including the UpCntIncrStable_A and DnCntIncrStable_A assertions and the existing fpv_force signal. Review the bounded increment behavior and the approach discussed in issue #22797. Done means the FPV test can reach the maximum count and exercise both saturation assertions without an impractical unbounded run.

Written by the indexing model from the issue text.