feat(init): install the official Redis skills with lock-aware reporting

[VaskoAtanasovRedis]

Stacked on #1101. The official redis/agent-skills install, with the PoC's managed-vs-user lock semantics.

What this slice does

• Primary path - the standard skills CLI: npx -y skills add redis/agent-skills -s '*' -a <agent>... -y (claude→claude-code, vscode→github-copilot), run in the project directory. Statuses are diffed from the skills-lock.json the CLI owns (v1 computedHash): first run created, re-run unchanged, upstream changes updated. Verified live: all 8 official skills install and re-read as unchanged.
• Managed-vs-user semantics: unmanaged skill dirs (present but not in the lock) are surfaced as a warning before install, and their fate is reported from disk truth afterwards - kept if the installer left them, updated if it replaced them. The global scope (--skills-global) reads only the names from ~/.agents/.skill-lock.json (its hash schema churns across versions) plus in-run content signatures.
• Explicit checkout: --skills-repo <dir> / $REDISCTL_INIT_SKILLS_REPO copies from a local redis/agent-skills checkout directly - offline-safe, and the seam that keeps the test suite hermetic.
• No npx and no checkout → skipped with the remedy in the note. Deliberate simplification vs the PoC: its clone-cache + shallow-clone fallback is not ported (a user without npx needs network for the clone anyway, and a stale cache never refreshes). Skills are additive; the onboarding still validates.

Two adjacent fixes surfaced by this slice's testing

• free_port now probes loopback + both wildcard families: Docker publishes ports on a dual-stack [::] listener the old IPv4-only probe missed - a leftover container holding 6379 made docker run fail with "port is already allocated". This bug exists in feat(init): provision and validate a local Docker database through plan/apply #1100 as reviewed; the fix rides here (happy to backport if preferred).
• Project-mutating commands run in the plan's cwd (sh_in), not the process cwd - the CLI masked this (process cwd = project), but the future MCP consumer would have installed into the wrong directory.

What it deliberately defers

• The generated redis-project-setup skill + .claude/skills symlinks (next slice), MCP, wizard, cloud, products, telemetry.

Test notes

• All hermetic tests route the skills step through a fixture checkout via REDISCTL_INIT_SKILLS_REPO; one #[ignore] test codifies the real npx path (network + npx).

Verify by hand

cd $(mktemp -d)
redisctl init --url redis://127.0.0.1:9 --no-install-cli   # npx path: 8 skills + skills-lock.json (validation fails by design)
redisctl init --url redis://127.0.0.1:9 --no-install-cli   # all '= unchanged … npx skills add'