[17.0.0-rc.0] migrate CLI and dev runtime disagree on __search companion provisioning — migrate flags live search columns as destructive orphans #3955

Found during the HotCRM 17.0.0-rc.0 upgrade (tag commit fc156fa4a). Reproducible column-level evidence below.

Symptom

os migrate plan against a database created by objectstack dev reports 9 destructive drop_column ops for __search companion columns (crm_task, crm_competitor, crm_opportunity_line_item, crm_quote_line_item, sys_metadata, sys_metadata_history, sys_metadata_commit, sys_metadata_audit, sys_view_definition):

crm_task.__search: column exists in the database but not in metadata (orphaned) — "os migrate apply --allow-destructive" to drop it.

Evidence — the two boot paths build different schemas from the same source tree

Same worktree, same artifact, two fresh databases:

And os migrate plan against its own freshly created DB reports 0 destructive changes — i.e. the "orphans" appear exactly when the DB was born under the dev runtime and judged by the CLI.

Why this is worse than a cosmetic warning

• The columns are not orphans: they are the search-companion columns (provisionSearchCompanion / plugin-pinyin-search) the dev runtime provisions and maintains. Following the CLI's own remediation advice (--allow-destructive) deletes live feature columns; the next dev boot presumably re-provisions them — churn at best, broken search at worst.
• Every dev-created SQLite database permanently nags with 9 destructive ops, training operators to reach for --allow-destructive.

Likely shape of the defect

The CLI boot (packages/cli/src/utils/schema-migrate.ts → runtime.start → syncRegisteredSchemas) either doesn't load the search plugin or computes companion eligibility differently from the dev runtime, so the metadata it diffs against lacks the __search fields for those 9 objects. Whichever side is "right", create/serve and plan/apply must share one schema view.

Related minor asymmetry (same family)

A brand-new CLI-created DB immediately reports the 3 "safe" replace_unique_index relaxations from #3696 (uniq_crm_contact_email → (organization_id, email) etc.) — i.e. the create path still emits the legacy platform-wide unique indexes that drift immediately wants to replace. The #3696 fix appears to have updated drift but not table creation.