fix(db): repair sequence counters and rebuild search index on partial import #1215

Summary

In main/routes/database.ts (POST /api/db/import), when a dataset containing orders or bills is imported without the sequences table (or with missing/lower sequence counters), executeSequenceRepair(db) was never executed, leaving live sequence counters in sequences stale.

Impact

1. Immediately following an import that includes orders/bills, creating the next order or bill fails with UNIQUE constraint failed: orders.order_number (or bills.bill_number) because the sequence generator reuses an already-persisted identifier.
2. Furthermore, restarting the app does not self-heal because PR fix(main): avoid historical scans during startup sequence repair #1203 introduced an ordinary startup fast-path that skips full historical scans when sequence_repair_completed_at is set and sequences table has existing entries.
3. In addition, rebuildSearchIndex(db) was not invoked upon import to index imported orders and customers into the FTS virtual tables.

Acceptance Criteria

• Executing POST /api/db/import with orders and bills omitting sequences advances sequences.current_value to at least the greatest imported recognized numeric suffix.
• The next order and bill generated in the same session succeed without unique constraint collisions.
• Reopening the database / app preserves the fast boot scan skip and continues sequential generation without collision.
• The FTS search index is rebuilt after import.
• Existing tests in test:database-tools-api and test:sequence pass.