reactor-search-index.json declares itself a generated artifact but has no merge driver — 5 open PRs, 4 blobs, silent auto-merge

Nobody has claimed this yet.

## Summary

`samples/ReactorGallery/reactor-search-index.json` is a **byte-for-byte generated artifact** — its own
`.gitattributes` entry says so — but it is left **fully line-mergeable**. Five open PRs currently carry
four distinct versions of it, and git will auto-merge them without a conflict.

## Measured

`samples/ReactorGallery/.gitattributes` on `main`:

```gitattributes
# The search index is a byte-for-byte generated artifact gated by
# SearchIndexGeneratorTests. Pin it to LF so the equality gate is deterministic on
# every OS/checkout regardless of core.autocrlf.
reactor-search-index.json text eol=lf
```

**It pins EOL and sets no merge driver.** The comment names the hazard exactly; the attribute one line
below does not act on it.

Blobs across the open queue:

```
main 20eeff32
#1003 b59af85e
#1004 9770d5d0 ┐ identical (one adopted the other's page, then regenerated)
#1005 9770d5d0 ┘
#1006 d579840a
#1009 98d8cfba
```

The file is **2,505 lines / 86,466 bytes of pretty-printed JSON**, so two PRs regenerating for
*different* control pages touch *disjoint regions*:

```
git merge-tree --write-tree --name-only <#1003> <#1006> -> exit 0 (no conflict)
git merge-tree --write-tree --name-only <#1003> <#1009> -> exit 0 (no conflict)
```

## What actually happens today

**The union is caught — but on the wrong PR.** `SearchIndexGeneratorTests.Index_IsUpToDate`
regenerates and byte-compares:

```csharp
var generated = Generate().Json;
var committedBytes = File.ReadAllBytes(CommittedPath());
if (!generatedBytes.AsSpan().SequenceEqual(committedBytes)) { throw ... "is stale" }
```

So a semantically wrong auto-merge **fails loudly**. The problem is *where*:

1. PR **A** merges and rewrites `main`'s index.
2. PRs **B…E** are now stale, and their indexes auto-merge cleanly on the way in.
3. The resulting `main` index disagrees with a fresh generation.
4. **The next PR's CI goes red on `Index_IsUpToDate`** — a PR that changed nothing related.

**The failure is loud, correctly detected, and misattributed.** In a repo that currently has several
documented ways for a leg to redden for reasons unrelated to the diff, a red on an unrelated PR is
the shape most likely to be re-run rather than read.

## Proposed change (one line)

```gitattributes
reactor-search-index.json text eol=lf -merge
```

`-merge` (or `merge=binary`) makes git **refuse to auto-resolve** and raise a conflict instead. That
mechanically enforces the rule that is currently carried by convention:

> **Adopt the conflicting sources first, regenerate second, never side-pick.**

It moves the failure from *"a later PR's CI, attributed to the wrong author"* to *"a conflict, in
front of the person doing the merge, with the context to resolve it."*

## Why it is a queue-level call

**Five open PRs modify this path**, so a `.gitattributes` change lands in all of their merges and will
introduce a conflict on each. That is the intended behaviour, but it is work for five sessions and
should be a deliberate decision about timing rather than something slipped in.

Filed rather than applied, for that reason.

## Credit

Found by the session on PR #977 while re-checking an overlap claim; the `.gitattributes` file, the
blob divergence, and the clean auto-merge were all verified independently before filing.

Related: #993.

Review samples/ReactorGallery/.gitattributes and the five open PRs modifying reactor-search-index.json, then read SearchIndexGeneratorTests.Index_IsUpToDate to understand the existing safety check. Confirm the merge behavior with the documented git merge-tree cases and verify that the chosen attribute makes competing generated versions require explicit resolution without breaking the generation test.

Written by the indexing model from the issue text.