feat(index): maintain a versioned ProjectAtlas database for released main

[styler-ai]

Why

Every clone and Git worktree currently owns an isolated writable .projectatlas/projectatlas.db. That isolation is correct, but a missing local atlas must rebuild the complete repository index and curated purposes even when the same released main tree was already indexed elsewhere.

ProjectAtlas should distribute one maintained, versioned .projectatlas baseline for the latest released main. A checkout can start from that complete baseline and incrementally reconcile only its local source differences instead of rebuilding from scratch.

This is database distribution and maintenance, not Git management.

What Changes

• Maintain a complete, integrity-verifiable ProjectAtlas database baseline for the exact released main revision, including the normal indexed graph and curated purpose state.
• Incrementally refresh the canonical baseline when merged changes add, modify, move, or remove indexed files and folders; verify the exact baseline again during release publication.
• Let a clone or existing Git worktree materialize its own writable local atlas from a compatible baseline, bind it to the local root, and run the existing incremental refresh over only the checkout's differences.
• Preserve an already valid local atlas instead of silently replacing it.
• Fail closed with typed recovery when the baseline is missing, corrupt, incomplete, or incompatible with the runtime, schema, configuration, or released source identity; the existing full initialization path remains the safe fallback.
• Measure repository/storage growth and initialization work before choosing the simplest durable representation for the versioned baseline.

Capabilities

• Maintained and versioned ProjectAtlas database baseline for released main.
• Fast initialization of clones and existing worktrees from that baseline.
• Incremental integration of merged file/folder changes into the canonical baseline.
• Safe private writable atlas ownership after materialization.

Architecture Diagrams

• Database authority and responsibility
• Index and transactional publication flow

Before this issue moves to status:ready, its OpenSpec change must update these versioned architecture views with the exact baseline publication, materialization, incremental refresh, failure, and recovery flow.

Release Scope

Backlog feature intended for v0.4.6. Do not add it to the v0.4.5 milestone or RC1 scope. Assign a v0.4.6 milestone only after that milestone exists and the issue has complete implementation-ready OpenSpec artifacts.

The expected implementation surface is the existing SQLite database, initialization/scan/watch boundaries, release workflow, CLI/MCP initialization behavior, and packaged-agent E2E coverage. It should reuse the current schema and incremental indexing path unless measurement proves a necessary compatible change.

Non-Goals

• Creating, removing, moving, switching, merging, pushing, or otherwise managing Git branches or worktrees.
• One live writable SQLite database, WAL, or lock shared concurrently by multiple roots.
• Binary-merging branch databases or treating a worktree atlas as the authority for another worktree.
• A database service, synchronization daemon, fleet telemetry system, purpose-promotion workflow, new TUI, or second storage layer.
• Replacing or resetting a valid local atlas without explicit user intent.
• Any change to v0.4.5 or v0.4.5-rc1 scope.

Pre-Mortem

Likely failure modes:

• The versioned database retains an absolute path or live WAL state and is not portable.
• The baseline claims one release/source tree but contains stale or partial index rows.
• Materialization overwrites valid local authored state or lets two roots write the same database.
• A schema, runtime, configuration, or ignore-policy mismatch produces subtly incorrect results instead of a typed fallback.
• Repeated binary updates cause unacceptable repository or release-artifact growth.
• The fast path still parses the full repository, so it saves neither time nor agent work.

Mitigations to carry into the OpenSpec checklist:

• Checkpoint and integrity-check the baseline, bind source identity explicitly, and exclude live WAL/SHM state.
• Verify baseline-to-release identity and incremental add/change/delete behavior before publication.
• Copy or otherwise materialize one private writable atlas per exact root; preserve an existing valid local atlas.
• Reuse current compatibility and migration guards, with a typed full-initialization fallback.
• Measure persistent bytes and update amplification before selecting the checked-in or packaged representation.
• Add one holistic E2E proving baseline publication, fresh-clone/worktree materialization, delta-only refresh, purpose preservation, private-root isolation, and CLI/MCP agent use on supported platforms.

OpenSpec Tasks

OpenSpec change: to be assigned