fix: Bound the MR security scan readiness poll interval

What does this MR do and why?

The merge request security widget has two readiness pollers, one on the Reports tab and one on the Overview tab. Both refetched enabledScans every 3 seconds with no growth and no maximum interval, so any pipeline that left ready false (for example a blocking manual job before the scan) polled forever at a fixed rate while the widget showed "loading".

This gives both readiness pollers the same backoff and 30s ceiling the per-report poller already uses, so the interval grows instead of hammering the endpoint.

This does not close the issue. #631073 asks for the poll to stop after a deadline or attempt limit and for a terminal state that names the scans that have not reported. A ceiling alone bounds the request rate, not the poll, which is why the issue lists this as possible fix 2 and notes that it "does not bound the poll". The deadline and the terminal state are still open.

Changelog: fixed Related to #631073

Before / After

Before: Both readiness pollers used incrementByFactorOf: 1 and no maxInterval, so a pipeline stuck with ready: false hit the endpoint at a fixed 3s rate for as long as the page stayed open. The customer HAR on the issue was captured on the Overview tab and shows exactly that: 12 enabledScans requests in 30 seconds, every one HTTP 200 with ready: false.

After: Both pollers back off (incrementByFactorOf: 1.5) up to a 30s ceiling (maxInterval). The request rate on a long-pending pipeline drops by an order of magnitude. The loading state itself is unchanged — it still does not end, and that is what the remaining issue work covers.

Approvals

The second commit touches ee/app/assets/javascripts/vue_merge_request_widget/widgets/security_reports/, which has a Security Insights frontend CODEOWNERS entry, so this MR needs that approval in addition to the usual one. The Reports tab path has no CODEOWNERS entry. The two changes are in separate commits if it is preferable to land them apart.

How to set up and validate locally

1. Run both specs:

   yarn jest ee/spec/frontend/merge_requests/reports/security_scans/security_scans_provider_spec.js ee/spec/frontend/vue_merge_request_widget/widgets/security_reports/mr_widget_security_reports_spec.js

   Each asserts the SmartInterval configuration its component constructs, so dropping either source change fails the matching spec.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.