Define and deliver cross-platform base-cli support for Linux, WSL2, and native Windows

[codeforester]

Goal

Define and implement a supportable cross-platform contract for the generic base-cli framework.

Supported targets

• Linux distribution-neutral behavior, validated on representative Debian/Ubuntu and Fedora/RHEL-family environments.
• WSL2 when base-cli runs inside the Linux distribution.
• Native Windows 10/11 support for the generic Python CLI core, including Click invocation, runtime state, logging, history, and test helpers.

Explicit non-goals

• Making Base/basectl natively Windows-compatible in this train.
• Package-manager integration (apt, dnf, Homebrew, winget, Chocolatey).
• Translating paths between WSL and Windows or guaranteeing behavior on Windows-mounted WSL paths.
• Requiring Bash, PowerShell, or a specific shell for the generic library.

Acceptance criteria

• The platform support tiers and boundaries are documented.
• POSIX and Windows path, cache, permission, locking, terminal, and test-isolation semantics are explicit.
• Representative Linux, WSL2, and Windows validation paths exist.
• Existing macOS and Linux behavior remains covered.
• The work lands as issue-backed PRs with the child implementation issues linked here.

Proposed train

1. Platform-aware paths and home/path normalization.
2. Portable private-file permissions and history locking.
3. Native Windows test-helper and terminal behavior.
4. Linux distribution and WSL2 validation.
5. Support documentation and release-readiness updates.

Base-specific native Windows support remains a separate effort.

[codeforester]

The implementation train is now split as follows:

1. #36 — platform-aware cache paths and home/path normalization
2. #37 — portable private-file permissions and history locking
3. #38 — native Windows testing and terminal behavior
4. #39 — Linux distribution and WSL2 validation
5. #40 — support documentation and release readiness

Recommended sequencing: #36 and #37 can proceed in parallel; #38 follows them; #39 can proceed in parallel with #36–#38; #40 closes the train after implementation and validation.