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.