chore: rename database table task_item -> plans

[neoneye]

Summary

Closes the "Rename table name" TODO from `docs/plan.md`. Matches the Python `PlanItem` naming introduced in proposal #74 (which kept the DB table at its legacy `task_item` name to avoid a migration).

Migration strategy

• New helper `ensure_plans_table_name()` renames the table (and its two indexes) if and only if legacy `task_item` exists AND `plans` does not. Wrapped in a Postgres transaction-level advisory lock so the three services (`frontend_multi_user`, `worker_plan_database`, `mcp_cloud`) cannot race on startup — whichever replica grabs the lock first does the rename; the others no-op.
• Runs before `db.create_all()` so SQLAlchemy does not create a second empty `plans` table alongside `task_item`.
• `PlanItem.tablename` flipped from `"task_item"` to `"plans"`.
• All `ALTER TABLE` / `CREATE INDEX` / `SELECT` / `UPDATE` / `VACUUM` strings in the three services and admin routes now reference `plans`.
• Indexes renamed `idx_task_item_` → `idx_plans_`.
• Admin template wording and the `_vacuum_task_item()` helper renamed to `_vacuum_plans()`.
• Log messages updated.

No zero-downtime guarantees: during a rolling deploy, a still-running old replica will fail queries against the new name until it gets redeployed. User confirmed this is fine (no users on Railway).

Test plan

• CI passes
• Fresh DB: `docker compose up` creates a `plans` table, no `task_item`
• Existing DB (Railway): first replica boot renames `task_item` → `plans` atomically, subsequent replicas no-op
• Admin panel: size info, purge, and vacuum still work against the renamed table
• End-to-end plan_create → plan_status → report download works

🤖 Generated with Claude Code