Remove remaining Base consumer coupling from base-cli

[codeforester]

Summary

Make base-cli a fully standalone, consumer-neutral Python CLI library. Base is a consumer of the library, not an implicit dependency of its lifecycle.

The consumer-profile boundary introduced in #17 and the explicit Base adapter in Base are the right direction, but base-cli still ships a large legacy_base compatibility profile plus Base-owned paths, configuration, manifest discovery, runtime ownership, and history policy.

Refactor phases

1. Make App() select the generic profile by default; keep the legacy profile only as a temporary, explicitly named compatibility surface.
2. Move Base discovery, configuration, runtime, and history adapters into the Base repository and have Base construct its profile there.
3. Rename or generalize remaining public context/configuration fields whose names encode Base concepts.
4. Remove the legacy compatibility profile and its Base-specific modules from base-cli.
5. Update documentation, tests, and public API checks. Package rename is explicitly out of scope.

Acceptance criteria

• A standalone consumer that imports base_cli has no implicit Base manifest, home, cache, config, runtime, or history behavior.
• Base behavior is supplied entirely by Base-owned adapter code.
• No Base product names, paths, environment variables, command lists, or persistence schema remain in generic lifecycle modules after the migration.
• Existing Base behavior remains covered by Base tests throughout the train.
• Each phase lands as a reviewable issue-backed PR with migration notes where public API compatibility matters.

[codeforester]

Resolved by the completed consumer-neutral refactor. The planned phases shipped through #21, #25, #26, #29, #30, and #32; current main is fc3ac18 and the generic package no longer carries Base lifecycle, adapter, schema, or command-policy residue. Closing this umbrella issue; remaining release and repository-cleanup work is tracked separately in #33 and #34.