feat(cli): add Termux support and curl installer

[continued-agent]

Summary

• rename the published CLI package to continued-agent while keeping the cn command
• add isolated, unit-tested Termux platform detection inside extensions/cli
• replace the existing installer bootstrap path with an npm-based installer that uses the Termux-provided Node.js/npm runtime
• add the documented Termux curl installation command and security warning
• add an automatic CLI release workflow that publishes continued-agent to npm with semantic-release

Termux detection

Termux is detected only on Linux when a Termux version marker (TERMUX_VERSION or TERMUX_APP__VERSION_NAME) is present together with a Termux $PREFIX path under a com.termux* app directory. This avoids relying on process.platform === "android" and avoids classifying ordinary Linux as Termux.

Installer

The installer:

• supports Termux architectures aarch64, arm, i686, and x86_64
• checks Node.js >= 18 and npm
• tells Termux users to install/update them with pkg when necessary, without invoking pkg automatically
• never uses sudo
• never installs fnm
• never downloads or executes a secondary remote shell script
• installs with npm install --global continued-agent
• does not modify shell configuration
• reports PATH issues without silently changing PATH
• handles non-interactive execution without attempting an interactive package-manager operation

Release automation

.github/workflows/cli-release.yml runs for CLI-related changes on main, builds the CLI, and invokes the existing semantic-release configuration. It requires the repository secret NPM_TOKEN for npm publishing and uses the normal GITHUB_TOKEN for GitHub releases.

Validation status

The GitHub branch and commit were created, but this environment cannot execute the repository's local Node/npm toolchain or a real Termux environment. No claim of real Android/Termux validation is made. The added TypeScript tests and shell installer still require execution by CI/local tooling.

Limitations

• real Termux device validation remains required
• npm package-name availability should be confirmed before the first production publish
• the existing CLI package-lock metadata still names the former package and should be regenerated with the repository's npm version before the release workflow is enabled for the first production publish