Add remediated_at field to vulnerability ES index mapping

What does this MR do and why?

Adds remediated_at to the vulnerability Elasticsearch index mapping so it can be indexed. The mapping is dynamic: 'strict', meaning Elasticsearch rejects any document field that isn't explicitly declared. An upcoming MTTR (mean time to remediate) chart will aggregate vulnerabilities by remediation date in Elasticsearch, so this mapping needs to land before anything writes the field.

This is mapping-only: no database column, no population of the field, and nothing exposed via the API.

Vulnerability data is dual-written to both the vulnerabilities and vulnerability_reads indices, so this adds two advanced search migrations (with their dictionary files and specs) to apply the mapping to existing indices. Search::Elastic::Types::Vulnerabilities::Read inherits the new field via super.merge(...), so only one mapping file needed a direct change.

This follows the same pattern as the organization_id mapping added in commit 899b867a.

First of nine issues in the MTTR chart - Backend epic.

Closes #627294 (closed)