feat(soe): enable ls/grep colour using each OS's own defaults

[catinspace-au]

Colouring is off on any box whose home directory did not come from the distro's own skel. A Fedora-derived .bashrc on Ubuntu leaves LS_COLORS empty with no ls alias, so ls and the prompt render monochrome.

Uses only what each OS ships, nothing installed. GNU ls (Linux, or macOS with coreutils on PATH) reads LS_COLORS; BSD ls ignores LS_COLORS entirely and reads LSCOLORS, so the block detects which ls it has at shell start.

Colours are ANSI indices rather than RGB, so they track the terminal theme and need no light/dark handling of their own — Solarized keeps 14 of 16 palette slots identical across its light and dark variants.

Goes in the interactive shell rc, not /etc/profile.d: aliases are not exported, and Ubuntu ships its profile.d hook commented out in /etc/bash.bashrc, so a terminal's non-login shell never reads it.

System-wide by default; soe_ls_colour_scope=user writes to the invoking user's rc instead and needs no root.

scope	Ubuntu	Fedora	macOS
system	/etc/bash.bashrc	/etc/bashrc	/etc/zshrc
user	~/.bashrc	~/.bashrc	~/.zshrc

Verification

• Ubuntu 26.04, real run: block at /etc/bash.bashrc, LS_COLORS 1753 chars, alias set, root sees it too, second run changed=0
• macOS, real run: block at /etc/zshrc, took the BSD branch correctly (plain dircolors not on PATH), ls emits bold blue dirs / bold magenta symlinks
• Fedora untested — no reachable box; /etc/bashrc path and the colorls.sh no-op assumption are unverified
• ansible-lint + yamllint clean for the new section; the remaining failures are pre-existing on main

Note

macOS and Linux will not match colour-for-colour: LSCOLORS has 11 slots, LS_COLORS has dozens. Closing that gap needs coreutils' gnubin on PATH, which was deliberately not done.