Closes #404 (follow-up to #400 / phase 2 blocker for #399).

Problem

app_lifespan allocates six resources before yield:

1. webhook_mgr (if enabled)
2. ctx (AppContext)
3. comp (via ctx.ensure_initialized() — opens DB/embedder)
4. watcher (FileWatcher.start())
5. scheduler + policy_scheduler (if enabled)
6. watchdog (if enabled)

The old shape only guarded the body behind yield with try/finally. If any step between the first allocation and yield raised, the finally block never ran and everything already allocated leaked.

ensure_initialized() has its own internal try/except close_components (PR #400), so the DB handles it opened are covered. But the rest — webhook_mgr, watcher, scheduler, policy_scheduler, and the just-constructed watchdog — all leaked if startup failed after them.

This becomes a Phase 2/3 blocker for #399's lazy-init refactor: once the DB open moves into request handlers, a late allocation failure (e.g. scheduler.start() racing against network state) becomes more likely than it is in eager-init, and a stale flock on ~/.memtomem/memtomem.db becomes user-visible.

Fix

Factor the teardown sequence into _teardown_startup_resources and call it from both paths:

• Normal shutdown — try/finally after yield, same as before, now routed through the helper.
• Startup failure — new try/except BaseException around the entire allocation block that runs teardown before re-raising.

Teardown order matches the inverse of allocation. Each step swallows its own exception so a late failure doesn't skip earlier steps — shutdown must always complete whatever it can.

Note on ctx.close() in the teardown path: AppContext.close() is idempotent (_components is None → no-op) and ensure_initialized()'s internal rollback leaves _components unset on failure, so calling ctx.close() from _teardown_startup_resources after an ensure_initialized failure is a safe no-op. No double-close.

Tests

• Unit (_teardown_startup_resources):
  • All-None input → no-op, no error.
  • All present → reverse-allocation order (watchdog → … → ctx).
  • Intermediate failure → later steps still run.
  • ctx.close() is always the final step.
• Integration (test_startup_failure_tears_down_prior_resources):
  • Inject a failing HealthWatchdog.start().
  • Verify ensure_initialized, watcher, scheduler, policy_scheduler, webhook_mgr, and watchdog.stop() all run in reverse order.
  • Verify the original RuntimeError("watchdog boom") re-raises.

Test plan

• uv run pytest packages/memtomem/tests/test_server_lifespan.py: 5 passed.
• uv run pytest -m "not ollama": 2168 passed (no regressions).
• uv run ruff check + ruff format --check: clean.
• uv run mypy packages/memtomem/src/memtomem/server/lifespan.py: clean.

Not in scope

• Actually moving to lazy init (Phase 2/3 of Lazy DB init: defer ~/.memtomem/memtomem.db creation until first tool call #399) — this PR only closes the teardown gap so the subsequent phases can land safely.
• webhook_mgr construction is storage-free and currently cannot raise in practice; we still route it through the same teardown seam for consistency.