Back to Search-quality baseline: symbol-attribute (Phase 1.6, v1.2.0 candidate)

The split is consistent with cupertino's actual search architecture. The default search path goes through FTS5 over `docs_fts` columns (`uri`, `source`, `framework`, `language`, `title`, `content`, `summary`, `symbols`, `symbol_components`). It does NOT consult `doc_symbols.kind`, `doc_symbols.is_async`, `doc_symbols.attributes`, or `doc_symbols.conformances` directly.

A query for `@MainActor` works because the literal token `MainActor` appears in `docs_fts.symbols` (extracted by ASTIndexer at index time) and in `docs_fts.content` (Apple's prose mentions @MainActor). A query for `initializer` does NOT work because the token `initializer` rarely appears in titles or content (the title might say `init(_:)` instead), and the `kind='initializer'` filter is not part of the default search path.

This is architecturally consistent with the database design documented in `docs/architecture/database.md`. The `doc_symbols` table is a relational store for symbol-level metadata; the default FTS5 search is a separate path. The intended access pattern for attribute-style queries is via `Search.Index.SearchByAttribute` (file: `Packages/Sources/Search/Search.Index.SearchByAttribute.swift`), which exists in the codebase but is invoked only by code paths that explicitly want filter-based search, not by `cupertino search "<query>"`.

For an LLM agent or human typing `cupertino search initializer` and expecting initializer-defining pages, the current path returns nothing useful. To get attribute-filtered results today the consumer must reach for filter-style query operators that the CLI does not currently expose as a first-class flag.