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

Per the `feedback_code_changes_as_ideas_for_future` rule:

1. CLI flag for kind-based filtering. `cupertino search --kind initializer` or `--kind actor` would route through `SearchByAttribute` and return all pages with at least one matching symbol. Small CLI surface change; harness logic already exists. Highest-value first move.
2. Heuristic intent routing for attribute queries. Queries that match the pattern `^(async|throws|public|static|init|subscript|typealias|@\w+|.* conformance)$` route through `SearchByAttribute` automatically. More work, but no flag-discovery burden on the consumer.
3. Augment FTS5 with attribute tokens. Add a `attributes` column to `docs_fts` containing concatenated per-page attribute / conformance strings, BM25F-weighted (similar to `symbols`). Largest surface change; affects schema (`user_version` bump); requires reindex.

The acronym audit (`search-quality-acronym-baseline-v1.2.0.md`) raised analogous concerns about `framework_aliases.synonyms` not being consulted at FTS5 ranking time. Both audits point at the same broader pattern: cupertino's relational metadata tables are richer than the default FTS5 search path consults. A consolidated design for "non-text search modes" could address both classes simultaneously.