fix(adf): `adf init --module <name>` should be additive when .ai/ exists

[SmartBrandStrategies]

Summary

charter adf init --module frontend fails with a misleading message when .ai/ already exists:

.ai/ already exists at .ai/
Use --force (or --yes) to overwrite.

The --module flag implies adding a single module to the existing directory, but the command treats it as a full re-initialization. Using --yes works but regenerates all files (manifest.adf, core.adf, state.adf) — potentially overwriting customized content.

Steps to Reproduce

charter bootstrap --yes          # creates .ai/ with core.adf, state.adf, manifest.adf
# customize core.adf ...
charter adf init --module frontend   # fails
charter adf init --module frontend --yes  # works but regenerates everything

Expected Behavior

adf init --module <name> with an existing .ai/ directory should:

1. Create only the specified module file if it doesn't exist
2. Register it in the manifest if not already listed
3. Leave all other files untouched

Actual Behavior

• Without --yes: fails entirely with "already exists" error
• With --yes: recreates all ADF files, potentially losing customizations to core.adf

Suggested Fix

Separate the "add a single module" path from the "initialize entire ADF directory" path. When --module is specified and .ai/ exists, operate additively on just that module.

[SmartBrandStrategies]

Update: v0.5.0 branch (docs/adx-005-cli-ux-feedback) partially addresses this with the new charter adf create <module> command, which is properly additive — creates the file and registers it in the manifest without touching other files.

However, adf init --module <name> itself is unchanged. Since adf create covers the use case, this could be resolved by:

1. Documenting adf create as the canonical way to add modules, or
2. Having adf init --module delegate to adf create internally

Either way, the user-facing friction is resolved by adf create. Consider closing this in favor of documenting that path.