Support database-optional worktree lifecycle

[pkudinov]

Parent: #11

Problem

wt currently requires baseDatabaseName, a root .env containing
DATABASE_URL, and working Postgres administration for new, fresh setup,
remove, prune, and doctor. Port allocation, env seeding/patching, Git
worktree creation, and optional Docker services do not inherently require a
managed local database, so this blocks cloud-hosted, non-Postgres, and
ports/env-only users.

Desired outcome

Make database provisioning an optional, persistent repository capability while
preserving the current local-Postgres behavior for existing configurations.

The exact configuration shape should be selected during design, but it must
distinguish:

• managed Postgres template cloning (today's behavior and backward-compatible
  default), and
• no managed database lifecycle.

Logical per-slot database naming must be decoupled from physical provisioning.
In no-managed-database mode, a project may still opt into a derived name such
as app_wt3 for the existing database env patch and {{dbName}} templates,
without wt connecting to or creating that database.

Acceptance criteria

• Existing wt.config.json files and version-1 registry entries retain their
  current behavior without migration work by users.
• A repository can configure wt new and fresh wt setup to run without
  DATABASE_URL, the pg admin client, or any create/existence check.
• remove, prune, and doctor skip managed-database operations and
  diagnostics for allocations created without a managed database.
• Registry state and human/JSON output represent whether a database is
  managed, logically named only, or absent; teardown relies on persisted
  allocation state rather than the current config alone.
• The existing database env patch can rewrite a pre-provisioned/cloud
  connection string when a logical per-slot name is configured.
• Docker/env templates have defined behavior when no dbName exists and
  produce a clear validation error if configuration references an unavailable
  value.
• Rollback never attempts to drop an externally managed or logically named-only
  database.
• Tests cover new, setup, rollback, remove, prune, doctor, config
  compatibility, registry compatibility, env patching, and output in both
  managed and unmanaged modes.

Out of scope

• Arbitrary provision/remove hooks or a general plugin system.
• Provider-specific database creation for RDS, Neon, Supabase, Atlas,
  PlanetScale, or similar services.
• Concurrency-safe slot reservation, tracked separately under Feature request: DB-optional mode — use port + env isolation without a local Postgres (for parallel multi-agent worktrees) #11.