[Feature] Profiles / Features / State V2 (PR-1) #162

Problem

Profiles (governance levels) and capabilities (features) are entangled; the
Multi-Forge architecture requires a project-scope feature model with a State V2
schema, atomic feature switching and provider template sets — without weakening
the existing lifecycle ownership, transaction and migration guarantees.

Source: Multi-Forge v1.3.2-final §25–32 (PR-1, PR-1A/1B/1C).

Expected outcome

ainative installs a governance profile (standard/verified) and, independently,
optional features (forge-github, forge-gitlab, ...). State V2 carries
active_features[]; a single shared project_install_state() projects V1 state
read-only; migration is idempotent and never resurrects absent files.

Acceptance criteria

• Blocked until [Architecture] Separate governance profiles from optional capabilities #23 (accepted Feature model) AND ADR-MF-01 are accepted.
• PR-1A — Feature model and state projection: Feature model with
  components[]/conflicts[]; State schema V2 with active_features[];
  shared project_install_state(); read-only V1 projection; V2 validation.
  Tests: V1 standard → projected forge-github; V1 verified → projected
  forge-github; V1 + GitLab remote → forge-github compatibility default;
  V1 + no remote → forge-github compatibility default; V2 one forge →
  valid; V2 zero forge → valid; V2 GitHub+GitLab →
  STATE_CONFLICTING_WORK_FORGE_FEATURES; project_install_state() is
  idempotent.
• PR-1B — Atomic feature switching: feature enable, feature disable,
  feature switch, feature switch none in one lifecycle transaction:
  acquire project lifecycle lock → reload state → project effective V2 →
  plan → apply → verify → write state V2 last → commit.
• PR-1B migration neutrality: a V1→V2 migration never resurrects a previously
  managed file that is currently absent (fixture: state says the GitHub
  template existed, file is absent → stays absent); an explicit later
  feature enable may seed feature files normally; no permanent file
  tombstones.
• PR-1C templates: github-templates ID preserved; gitlab-templates added
  with .gitlab/issue_templates/ and .gitlab/merge_request_templates/ where
  applicable; existing ownership semantics preserved.
• Ownership matrix tests: managed unchanged → replace/update allowed; managed
  modified → conflict/preserve; not managed → never silently adopted;
  removed feature + modified file → preserve; manually absent during
  migration → remains absent; user collision → conflict.
• Round-trip tests (zero user-data loss): GitHub → GitLab → none → GitHub for
  unchanged template, modified template, missing template, colliding user
  file.
• Read-only parity: doctor, status, planner, feature status,
  update check all derive feature state through the same projection; E2E:
  V1 state → read-only status → later V2 migration → effective feature set
  identical.
• No new lifecycle transaction system; existing journal/backup/repair/
  rollback and state-last invariants preserved.

Out of scope

• Workflow neutralization and claims (PR-2), forge observation (PR-3), release V3
  (PR-4), GitLab provider (PR-5).
• GHES support; universal Forge SDK.

Context

• Issue [Architecture] Separate governance profiles from optional capabilities #23 — accepted Feature model (design gate).
• ADR-MF-01 — Generic Git / Features / State.
• ainative/lifecycle/state.py, installer.py, planner.py, manifest.py.
• Split into PR-1A/1B/1C if the logical PR exceeds 400 changed LOC.

Dependencies

• Blocked by [Architecture] Separate governance profiles from optional capabilities #23 (accepted Feature model) and ADR-MF-01 ([Docs] ADR-MF-01 — Generic Git / Features / State (design gate for PR-1) #160).
• Blocks PR-2 ([Feature] Neutral workflow, Work Authority and claim journal (PR-2) #163) and PR-3 ([Feature] Forge observation and doctor extensions (PR-3) #164).