[Docs] Explain initialization prompts, changes, and later management

[divyarajmasani]

Parent epic: #768 — Documentation epic

Base branch: theme-elementary-v2. Cover its functionality and subsequent changes based on it. Verify against the latest relevant v2 implementation and record the tested commit in the documentation PR.

Problem and scope

Developers cannot easily distinguish project acquisition from initialization or predict what cleanup changes. Create docs/initialization.md around the decisions and results of init.

Proposed structure

1. Before init: dependency prerequisites, intended theme directory, and clean-tree requirement.
2. Entry points: acquisition via Composer/clone, CLI init, AI /init, and whether /setup applies to this skeleton.
3. What the prompts mean: name and derived identity, example selection, optional features, and cleanup.
4. What changes: a compact table of identity fields, affected files, retained/removed content, and generated configuration.
5. Review the result: verify identity, retained examples, and cleanup output; suggest a baseline commit before adding features.
6. Change something later: supported identity/feature management versus one-time example removal, based on verified behavior.
7. Troubleshooting: failed install, incomplete init, or missing retained functionality; give a check and recovery action.

Boundaries

This page owns skeleton-specific initialization and toggle commands. Link to the tooling reference for exhaustive engine flags and to the feature catalogue for descriptions. Explain any differences between CLI and AI behavior without duplicating AI skill instructions.

Verify cleanup behavior before documenting it. File separate implementation dependencies for broken cleanup or removed AI files with remaining references; do not make script repair an implicit documentation deliverable.

Acceptance criteria

• Acquisition, installation, initialization, and feature creation have clear entry and exit points.
• Each prompt explains its consequences and defaults.
• Developers can predict which files are retained, changed, or removed.
• Safe repeatable operations and one-time operations are distinguished.
• The post-init review checkpoint includes concrete checks and a suggested baseline commit.
• Commands match supported behavior; detailed engine options are linked upstream.
• Broken initialization behavior is captured as a linked implementation dependency.