Installer can write outside the target through symlinked destinations

## Problem

`install.sh` copies configuration into paths below `$HOME` without checking whether a destination or one of its child components is a symbolic link. As a result, an install can modify files outside the expected configuration directory.

I reproduced this on current `master` (`34d197b7e2ede7c57d11b601250b42b8a2ae303a`) with GNU `cp`.

## Reproduction

```bash
tmpdir=$(mktemp -d)
mkdir -p "$tmpdir/home/.codex" "$tmpdir/outside"
ln -s "$tmpdir/outside" "$tmpdir/home/.codex/skills"
HOME="$tmpdir/home" ./install.sh --skills

test -f "$tmpdir/outside/audit-ai-code/SKILL.md"
```

The same behavior occurs for an existing non-dangling prompt-file symlink: `install_cp_file` follows the link and replaces its external target.

## Expected behavior

The installer should not silently cross its destination boundary through a symlink. It should either refuse the install with a clear error or explicitly document and gate symlink-following behavior.

## Impact

This is most likely to cause accidental writes when an old or unexpected symlink remains in a dotfiles tree. Platform-specific `cp` behavior may vary, which makes an explicit installer check preferable to relying on the copy implementation.

Start by reading install.sh, especially install_cp_file, and run the issue's temporary-directory reproduction with ./install.sh --skills. Trace how destination and prompt-file paths are copied. Done means the installer no longer crosses the destination boundary through symlinks and either refuses with a clear error or applies an explicitly gated behavior.

Written by the indexing model from the issue text.