Add search api tests for translated canvas Page indexing and retrieval
## Problem Multilingual indexing of `canvas_page` already works via the `ComponentTreeInputs` Search API processor (`src/Plugin/search_api/processor/ComponentTreeInputs.php`) and `ComponentTreeInputExtractor`: Search API indexes each translation as its own item (`entity:canvas_page/123:es`) and the extractor resolves each translation's own string props. But existing Kernel tests only cover a single language. `ComponentTreeInputsTest` builds a real index (`entity:canvas_page` datasource, `search_api` + `search_api_db`), and `testWithQuery()` wires a real `search_api_db` server, indexes a Page, and queries it — that's the index+query pattern to reuse. `ComponentTreeInputExtractorTest` covers extractor behavior. None exercise a translation. This pins per-language behavior before the audit-langcode ("Support Language for ComponentAudit") and ContentTemplate indexing work builds on it. ## Proposed solution `PageTrait` has no translation helper (only `installPageEntitySchema()` and `assertSaveWithoutViolations()`), so the multilingual setup is part of this ticket: add `language` to `$modules`, create a second language (`ConfigurableLanguage::createFromLangcode('es')->save()`), and create the translation inline (`$page->addTranslation('es', [...])->save()`). Inline is fine for 2–3 cases; add a small `addPageTranslation()` helper to `PageTrait` only if reused more. Reuse the `testWithQuery()` retrieval pattern unchanged. Cases to add: 1. **Per-language isolation** — Page with `en` heading + `es` translation with translated heading; assert the `:en` item contains only the `en` string and `:es` only the `es` string (no cross-language bleed). 2. **Retrieval filtered by language** — query an `en`-only term returns only `:en`; an `es`-only term (or `$query->setLanguages(['es'])`) returns only `:es`. 3. **Untranslated props — no fallback** — the component tree is whole-translated; there is no field-level language fallback at the indexing layer (verified by spike). Pin both cases as *expected*: (a) a prop with no translated input in the `es` tree -> **absent** from the `:es` item (not the source value); (b) an `es` translation that never set `components` -> **empty** `:es` contribution. 4. **Filtering per translation** — confirm enum / ignored-prop (`id`/`class`/`cssClasses`/`extraClasses`) / Block-source exclusion still applies in the `es` translation. Extend `testExtractedInputs()` / `testCustomIgnoredPropNames()` with a translated row. ## Acceptance criteria - Multilingual cases added to `ComponentTreeInputsTest` (and `ComponentTreeInputExtractorTest` where cheaper) — no new class. - Proves `:en` and `:es` index only their own language's resolved string props. - A language-filtered query returns only the matching translation (real `search_api_db` query). - Pins the no-fallback behavior with an *expected* comment: untranslated prop -> absent from `:es`; untranslated `components` -> empty `:es` contribution.- Enum / ignored / Block exclusion verified in a translation, not only the source language. (Generated by Claude Opus 4.8. Modified and verified by me)
issue