[Final][Cases] Cases analytics v2 - Attachments Index (.cases-attachments) - #276117

…ents) (elastic#276117)

## Summary

Feature Flag: `xpack.cases.analyticsV2.enabled`

This is a follow up to elastic#269581 and elastic#275686, which introduced the cases
as data V2 work and its first two indices, `.cases` and
`.cases-activity`. This PR adds the third and final one,
`.cases-attachments`, which holds the case comments and attachments data
(one document per comment / attachment). The `Cases Analytics` data view
added in the first PR already points at all three indices, so this data
can be joined back to its case via `cases.id` using an ES|QL `LOOKUP
JOIN`.

Like the other two indices, `.cases-attachments` follows the same
approach set up in the previous PRs:

- Whenever a comment or attachment is created, updated, or deleted, we
asynchronously write the same change to the `.cases-attachments` index.
As with the other indices, this *will not* block the primary write from
happening if the analytics write fails.
- A reconciliation task runs periodically to check all comments and
attachments since the last run and make sure they've been written to
`.cases-attachments`. Each index is reconciled independently, so an
issue with one won't hold up the others.
- The `/reset` and `/reconcile/run_soon` admin routes and the initial
backfill now cover all three indices. The backfill and `/reset` rebuild
the three indices in parallel, and read saved objects in larger batches,
so a full rebuild finishes noticeably faster than doing them one after
another.

Of note:

- This index holds both the older case comments (cases-comments) and the
newer unified attachments (cases-attachments), normalized into a single
document shape, so it works whether or not a deployment has moved to the
new attachments saved object. Both source types are always mirrored and
reconciled, since the unified attachments saved object is always
registered. `xpack.cases.attachments.enabled` only affects which saved
object new attachments are written to — not what the analytics index
reads.

- Deleting a case also deletes its comments and attachments, so when a
case is deleted we make sure to remove its `.cases-attachments` docs as
well.

With all three indices now in place, a final PR will follow to remove
the existing V1 implementation. The current cases as data v1 work is
unaffected.

## Technical Implementation

For a complete set of details, please see:
`x-pack/platform/plugins/shared/cases/server/cases_analytics_v2/README.md`

## Testing

### Setup

Add to `config/kibana.dev.yml`:

```yaml
xpack.cases.analyticsV2.enabled: true
xpack.cases.analyticsV2.enableAdminRoutes: true

# Optional — makes NEW attachments write to the unified `cases-attachments`
# saved object (default is the legacy `cases-comments`). The analytics index
# mirrors/reconciles both source types either way.
xpack.cases.attachments.enabled: true
```

Restart Kibana, then open **Dev Tools → Console**.

### 1. Real-time writes

Create a case and add a couple of things to it (a comment, and an
attachment if you enabled `attachments.enabled`). Then confirm the data
landed:

```
GET .cases-attachments/_search
{
  "query": { "term": { "cases.id": "<case id>" } }
}
```

Each comment / attachment should have a matching doc, with the
attachment `type` and a few of the important fields pulled out for
easier analysis. Editing or deleting a comment should be reflected on
the next search (upsert / delete path).

### 2. Deleting a case

Delete the case, then re-run the search above → 0 hits (its attachment
docs are removed along with the case).

### 3. Reconciliation + reset

- `GET kbn:/internal/cases/_analyticsV2/state` now reports all three
indices (`.cases`, `.cases-activity`, `.cases-attachments`) and includes
`attachments_last_run_at` alongside the existing reconciliation info.
- `POST kbn:/internal/cases/_analyticsV2/reset` rebuilds all three
indices. Poll `/state` and confirm they all come back. While a reset is
running, `/state` reports a single `running` phase with the per-index
processed counts (`cases_processed`, `activity_processed`,
`attachments_processed`) climbing together, since the three rebuilds run
in parallel.

#### Automated coverage

```bash
node scripts/functional_tests \
  --config x-pack/platform/test/cases_api_integration/spaces_only/config_analytics_v2.ts

yarn jest --config x-pack/platform/plugins/shared/cases/jest.config.js cases_analytics_v2
```

### Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed

### Identify risks

Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.

- [ ] All changes are net new and behind
`xpack.cases.analyticsV2.enabled` (off by default); the primary case /
comment / attachment writes are never blocked by an analytics write, and
the reconciliation task backstops any missed writes.

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>