Test suite gap: array indexing composed with where() is never exercised

The suite contains only three test cases that use array indexing (`fhirpath > index[0]`, `index[1]`, `out of index`), and all three use the same simple shape: an index applied to a plain member chain (`name[N].family`). No test composes `.where()` with an indexer. The `fhirpath > where` case only navigates a scalar member after the filter (`name.where(use='official').family`).

This leaves a hole that silently hides defects in every runner: indexing a filtered collection (`X.where(...)[N]` or `X.where(...).field[N]`) requires the transpiler to combine the filter subquery with index extraction. Two runners I tested (a SQL Server runner and an Oracle runner) both emit broken SQL for `name.where(use = 'official').given[0]` while scoring 100% on the suite - for example, a bare `JSON_VALUE(value, '$.given[0]')` column with no lateral that materialises the filtered elements anywhere in the query, so `value` either fails to resolve or binds to an unrelated column. The Oracle runner returned wrong rows silently; it was only found by testing against a real dataset, not by the suite.

Suggested cases to close the gap:

- `name.where(use = 'official').given[0]` - index applied after a filter, then member navigation
- `name.where(use = 'official')[0].family` - index applied directly to the filtered collection
- `name.where(use = 'official')[1]` - pins the semantics when the filter matches multiple elements

The last case also settles an ambiguity runners currently resolve differently: FHIRPath collections flatten, so `[1]` selects the second element across all matching names, whereas a first-match-then-index shortcut (limiting the subquery to one row, then indexing inside it) diverges. A test for that shape would pin the intended semantics for all runners.

Resources for the cases would need two `name` entries per patient (one with `use: official`, one without) so the filter and the index both bite.

Locate the existing tests for the `fhirpath > index` and `fhirpath > where` cases, then review how their patient resources define `name` entries. Add cases for filtered collections followed by indexing and member navigation, using two names per patient, and run the conformance suite across the runners to verify filtering, flattening, and second-element semantics.

Written by the indexing model from the issue text.