[Suggestion]: Expose matched pattern identity from multiGrep

### Which fff frontend(s)?

- Node SDK (`@ff-labs/fff-node`)
- Bun SDK (`@ff-labs/fff-bun`)
- Core or Rust crate

### What problem are you trying to solve?

Hi! FFF has been useful in many places where I can piggyback on its exposed API.

I am using `multiGrep({ patterns })`, but each `GrepMatch` does not identify which input pattern produced it. Because `multiGrep` uses OR logic, a caller cannot distinguish a file that matches every pattern from one that repeats only one pattern.

For example, with:

```ts
patterns: ["recent", "PRs"]
```

A file containing both terms should rank above a file containing many instances of only `recent`. I can rank by the number of matching lines, but that rewards repetition rather than distinct pattern coverage.

Is there already a supported way to recover the matched pattern identity, or am I holding the API wrong?

### Proposed solution

Expose pattern identity in multi-grep results—for example, `matchedPatternIndexes` on each `GrepMatch`, or a pattern index alongside each `matchRange`. A per-file set or count of matched patterns would also support this use case.

The Aho-Corasick matcher appears to know the pattern ID while collecting matches, but the public result currently exposes only the ranges.

Start by tracing the multiGrep implementation and the GrepMatch result type in the Rust core and SDK bindings, then inspect how the Aho-Corasick matcher’s pattern IDs are collected. Done means callers can distinguish which input patterns matched, with the chosen result shape exposed consistently in the Node and Bun SDKs.

Written by the indexing model from the issue text.