Destructive migration in `migrate_consolidate_links_and_kind` drops task and comment tables with no rollback path

[ooloth]

Current state

Any hub user still on the old issue_links/general schema loses all task and comment history the moment they upgrade, because migrate_consolidate_links_and_kind in store/src/tasks.rs detects the old schema and immediately executes DROP TABLE IF EXISTS task_comments followed by DROP TABLE IF EXISTS tasks. The inline comment justifying this is "All data is test data — drop and regenerate is safe", but this migration runs in production on every hub startup against real task data.

Ideal state

• The migration to the new schema preserves existing task and comment rows using an additive strategy (e.g., ALTER TABLE … ADD COLUMN, renaming values in-place, or inserting from the old table into a new schema then dropping the original)
• No existing task or comment row is deleted as a side-effect of a version upgrade
• A rollback to the previous binary does not require re-running a migration to restore lost rows

Out of scope

• Rewriting other migrations in store/src/tasks.rs
• Changing the task or comment schema beyond what is necessary to preserve existing data during the transition

Starting points

• store/src/tasks.rs — lines 46–76: migrate_consolidate_links_and_kind, specifically the DROP TABLE IF EXISTS task_comments and DROP TABLE IF EXISTS tasks calls

QA plan

1. Create a hub SQLite database with a row in the old tasks table (with issue_links and general columns populated).
2. Run hub with the current code and open the database — expect the task row and any associated comment rows to still be present after migration.
3. Inspect the migration path in store/src/tasks.rs — expect no unconditional DROP TABLE calls on tasks or task_comments.

Done when

Any existing task and comment row survives a migration from the old issue_links/general schema to the new schema without being silently dropped.