wip: doctor/cli/docs/api to vector db consolidation; api hardening for descriptions, tenant, and scopes; migrations and conversions of all DALs to EF v10

docs/db/MIGRATION_STRATEGY.md

@@ -20,6 +20,10 @@ Current-state realities that must be accounted for in operations:
 - Multiple migration mechanisms are active (shared `MigrationRunner`, `StartupMigrationHost` wrappers, custom runners with custom history tables, compose bootstrap init SQL, and unwired migration folders).
 - CLI migration coverage is currently limited to the modules registered in `src/Platform/__Libraries/StellaOps.Platform.Database/MigrationModuleRegistry.cs`.
 - Registry module population is plug-in based (`IMigrationModulePlugin`) with one migration plug-in per web service.
+- Service plug-ins can flatten multiple migration sources into one service-level module (for example Scanner storage + triage) while preserving one runner entrypoint per service.
+- Consolidated runner behavior for CLI/API: when a module has no applied history rows, one synthesized `100_consolidated_<service>.sql` migration is executed from the service source set, then legacy per-file history rows are backfilled for upgrade compatibility.
+- Consolidated runner behavior is self-healing for partial backfill states: if consolidated history exists and only some legacy rows are present, missing legacy rows are backfilled before per-source execution.
+- This means one-per-service execution for first bootstrap, not a permanent single-row history model.
 - Platform migration admin endpoints (`/api/v1/admin/migrations/*`) use the same platform-owned registry for UI/backend orchestration.
 - Several services contain migration SQL but have no verified runtime invocation path in non-test code.