fix(frontend): retry quick-action migration on failure; reopen Templates tab

WHY THIS MATTERS
Two regressions in the assistant home's quick actions:

1. The one-shot localStorage-to-database migration stamped its "done" marker
   even when the updateQuickAction() calls failed. One transient API error
   during a user's first load after upgrading would permanently discard the
   quick-action preferences they had set in the old localStorage system -
   silent, unrecoverable data loss of user configuration.
2. "Draft from Template" used to open the document picker on the Templates
   tab (initialDocumentTab: "templates" in the pre-database quick action).
   The database-backed rewrite dropped the option, so the picker opened on
   Files - replicated live: click the quick action, the Add Documents modal
   opens with Files pressed and the user's templates a tab away.

WHAT IS A ONE-SHOT MIGRATION MARKER?
A flag ("mike.quickActions.databaseMigrated") that says "the legacy state
has been carried over, never look at it again". Such a marker must only be
written after the migration actually succeeded; writing it on failure turns
a retryable error into permanent loss. The updates are idempotent, so
retrying a partial batch on the next load is safe.

HOW THE FIX WORKS
- The marker is now only written when no migration update was rejected; on
  partial failure the merged state still renders but the marker stays unset
  so the next load retries.
- handleQuickAction() passes initialDocumentTab: "templates" for the
  template-drafting default again. The workflow title is the only stable
  handle the quick-action row exposes today (the same handle the migration
  itself matches on); if the user renames their copy the picker simply
  falls back to Files.

Found by review of PR #309 (Templates-tab regression captured on video).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E4PXCdenNH5Mqhm5Sre9Zs