Populate remediated_at on vulnerability ES documents at index time

What does this MR do and why?

Populates remediated_at on vulnerability Elasticsearch documents at index time. The value is the earlier of resolved_at and undetected_since, ignoring nils: the earliest point a vulnerability stopped being an open problem, either because it was resolved or because scans stopped detecting it.

An upcoming MTTR (mean time to remediate) chart will aggregate on this one field instead of reasoning over two separate timestamps.

Vulnerability data is dual-written to a vulnerabilities index and a vulnerability_reads index, so the same change is made in both ee/lib/search/elastic/references/vulnerability.rb and ee/lib/search/elastic/references/vulnerabilities/read.rb:

• Add remediated_at to FIELDS_WITH_MIGRATIONS
• Add a new highest SCHEMA_VERSIONS entry (26_07 for vulnerability, 26_05 for vulnerability_reads)
• Write the value via set_field, backed by a one-line private earliest_remediation_timestamp helper

Notes for the reviewer:

• The value is computed inline rather than in a new preloader, since both resolved_at and undetected_since are already in memory and no database access is needed. The specs' existing N+1 guard confirms no queries are added.
• The helper uses grep(Time) rather than compact, because undetected_since can be [] rather than nil when a record skipped preloading, and comparing Array with Time would raise. There's a code comment on this line.
• One pre-existing spec example asserted a hardcoded schema version that was really tracking the newest version overall, not the migration it named. It now asserts described_class::SCHEMA_VERSION so it survives future schema bumps.

No backfill is included here; existing documents get the field in a follow-up issue.

References

• Closes #627295 (closed)
• Epic: &23458
• Phase 1 (merged): !254185 (merged)
• Follow-up: #627296 (closed) (Elasticsearch backfill for existing documents)

Screenshots or screen recordings

No UI change, backend only.

How to set up and validate locally

Run the two updated spec files (requires a running Elasticsearch instance):

bundle exec rspec ee/spec/lib/search/elastic/references/vulnerability_spec.rb ee/spec/lib/search/elastic/references/vulnerabilities/read_spec.rb

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.