fix(portal): portal tasks use the shim bot id; move orphaned default schedules

[chinkan]

Closes #154

Problem

Portal-created tasks were stamped bot_id = "default". In a multi-bot config with no [[bots]] id default, owning_bot finds no Telegram bot for that id, so the task never sends.

Fix

• The portal now acts as the shim bot (Config::shim_bot: main, then default, else the first bot). Task create, list, runs, upcoming count, and edit/delete/enable/disable ownership all use PortalState::bot_id(). Single-bot configs (id default) behave exactly as before.
• On boot, when no bot is named default, rows with bot_id = 'default' move to the shim bot (reminders::adopt_default_schedules), and a warning logs how many moved. When a default bot exists, nothing moves. Old tasks keep sending instead of silently vanishing.
• No bot picker in this PR (PO decision; tracked as a separate requirement).

Out of scope

Portal web chat is unchanged. A schedule created from web chat gets chat_id = "web", which is not a Telegram chat, so changing its bot id alone would not make it deliver. That is a separate issue.

Tests

• task_create_uses_shim_bot_id (portal API): single-bot default, multi-bot with default + main, multi-bot without default. Each asserts the stored bot_id, that the task is listed, and that the portal can still disable it.
• adopt_default_schedules_only_without_a_default_bot (unit): no move with a default bot (single and multi), a move to the shim bot without one, other bots' rows untouched, and idempotent on re-run.
• cargo fmt --check, cargo clippy --locked --all-targets -- -D warnings, cargo test --locked: 923 tests pass.

QA config matrix

1. Single bot default: create a portal task, and it sends from that bot.
2. Multi-bot with default and main: a portal task sends from main; existing default rows stay on the default bot.
3. Multi-bot without default: on boot, old default rows move to the shim bot (see the warning log with the count); new portal tasks send from the shim bot.

[chinkan]

TL ACCEPT at db4072c (comment — same-account Approve blocked).

Matches locked AC: portal uses PortalState::bot_id() → shim_bot; boot adopt_default_schedules only when no default bot, with warn count; tests cover the three configs (API + unit). Out-of-scope chat_id=web correctly deferred (PO follow-up after #162).

Merge after Product GO + QA GO (three-config matrix) + CI (Analyze (rust) green; AI findings 402 non-block). No tag.