wrap/skills install has no discovery path for binaries installed via mise/aqua-registry (or any channel outside the curl installer's layout)

`ripwire` is now installable via mise/aqua-registry (https://github.com/aquaproj/aqua-registry/tree/main/pkgs/redhat-et/ripwire), which fetches the binary out of the release tarball and symlinks it onto `PATH` on its own. It does not reproduce the curl installer's layout contract of `/bin/ripwire` + `/share/ripwire/skills/`.

`wrapPrintSkillsLine` (`src/wrap.h:200-219`) only has two live discovery paths — (a) `./skills/install.sh` relative to cwd (a checkout), or (b) `/../share/ripwire/skills/install.sh` (the curl installer's staged copy). Any other install channel — mise/aqua, a distro package, a hand-copied binary — falls to case (c): a dead "clone the repo and run `skills/install.sh`" comment instead of a runnable command. `ripwire wrap claude` for a mise-installed binary never wires up skills, silently.

This will also recur on every future upgrade: skills aren't versioned with the binary once it's outside the curl-installer's own directory, so there's no path that keeps skills in sync with `ripwire --version` short of a full re-clone.

**Two directions worth a maintainer opinion on:**

1. **Embed the skills in the binary itself**, generated at build time (CMake step turning `skills/*/SKILL.md` into a baked-in header, ~384 KB uncompressed today), with a new subcommand (e.g. `ripwire skills install [--codex]`) that writes them to the standard agent skill dirs. Installer-agnostic by construction, and "update skills on upgrade" becomes "re-run the subcommand" since the skills are pinned to that exact binary build. Fits the G3 self-contained / G5 zero-dependency-CLI guardrails — no new install-path convention to maintain per channel.
2. **Extend the aqua-registry package** to also stage `skills/`/`hooks/`/`install.sh` next to the binary in a layout `wrap` can find. Weaker: it only fixes mise/aqua, leaves every other current and future distribution channel with the same gap, and aqua's registry format doesn't obviously support "also drop this sibling directory" for a `github_release` asset.

A third existing option is pointing users at [skillshare](https://github.com/runkids/skillshare) to sync the skills separately, but it currently hard-blocks on ripwire's own skill: it static-analyzes `SKILL.md` files for prompt-injection patterns and flags the illustrative example output in `skills/ripwire-security-scan/SKILL.md` (a fenced code block showing what ripwire's scanner reports for a real finding) as a live CRITICAL injection — see runkids/skillshare#279. Not something this repo can fix, but worth knowing before pointing anyone at it as the interim answer.

Happy to put up a PR for direction (1) if that's the preferred shape — wanted a steer first since it touches CMake and the CLI surface.

Start with wrapPrintSkillsLine in src/wrap.h:200-219 and trace its existing checkout and curl-installer discovery paths. Then inspect the skills/*/SKILL.md files and the CMake build configuration to assess the proposed embedded-skills direction versus aqua-registry staging. Done means a maintainer-approved direction, an installer-independent discovery or installation path, and skills that remain aligned with the binary version.

Written by the indexing model from the issue text.