feat: check paths directly, with tilde/variable expansion and prompt history

[iamteedoh]

What does this PR do?

Makes the script usable for its actual purpose: pointing it at a path and being told the permissions.

Two separate defects combined so that, on macOS, essentially nothing a user typed worked:

1. Paths were used verbatim. Every entry other than a bare absolute path — ~/Documents, $HOME/x, a quoted path, a Finder drag-and-drop my\ file.txt, an indented line, a CRLF line ending — was looked up as-is and reported as path does not exist. 7 of 8 realistic spellings failed.
2. The prompt rejected the thing people were trying to check. It only accepted a file listing paths, and validated with -f. Typing ~/Documents — a directory that plainly exists — was reported as "file not found", which sent people hunting for a nonexistent path problem.

Fixing (1) alone left the reported symptom unchanged, because (2) was the real blocker.

Changes

• Normalize each entry before lookup: strip a CRLF tail and surrounding whitespace, remove one surrounding pair of quotes, resolve backslash escapes, expand a leading ~/~user and $VAR/${VAR}. Trimming now happens before the blank/comment test, so a CRLF file no longer turns every blank line into a bogus path.
• Accept a path or a list: a regular file is read as a list (the original mode, unchanged); anything else that exists is checked directly. Adds --path/-P (repeatable) for the same thing non-interactively, plus bare-argument support.
• Honest errors: --file handed a directory now says "is a directory, not a list of paths" and points at --path.
• Readline prompt: arrow-key recall of earlier entries and full line editing. HISTFILE is cleared so a run never writes back to the user's shell history.
• Test suite (new): tests/run_tests.sh, wired into CI.

Design notes for review

• Expansion is hand-rolled, not eval. An input file must only ever name files, never run commands, so $(...) and backticks are left literal. Only well-formed identifiers are substituted. There are tests asserting command substitution stays inert.
• A literal name always wins. If the normalized form does not exist but the raw line does, the raw line is used — a file genuinely named lit_$HOME.txt still resolves. This makes the change strictly non-regressive.
• Three bash 3.2 behaviors were verified rather than assumed, each a silent bug otherwise: "${arr[@]}" on an empty array errors under set -u; read -e -p routes its prompt to stderr (which this script wants); colored read -e prompts need \001/\002 markers or readline miscounts the cursor column and corrupts the line on recall.

Related issue

DIR-2

Validation

git ls-files '*.sh' | xargs shellcheck          # clean
git ls-files '*.sh' | xargs -n1 bash -n         # clean
./tests/run_tests.sh                            # 33 passed, 0 failed
gitleaks git . --config .gitleaks.toml          # no leaks found

• 33 tests pass, including 4 pty-driven tests. The prompt and its arrow-key history only exist with a real terminal, so they cannot be covered by piping input; tests/interactive_test.py attaches the script to a pseudo-terminal and verifies recall by sending a literal \x1b[A. It is skipped when python3 is unavailable.
• The path-spelling tests are proven regressions: 14 of them fail against the pre-fix script; the ones that pass on both are the no-regression guards.
• Driven end-to-end on macOS (bash 3.2): the reported scenario now resolves at the prompt, via --path, and as a bare argument; list mode and --all matrix mode still behave.

Checklist

• git ls-files '*.sh' | xargs shellcheck passes
• git ls-files '*.sh' | xargs -n1 bash -n passes
• gitleaks reports no secrets in Git history
• Scripts and programs include a GPL-3.0-or-later SPDX header
• No secrets, tokens, credentials, or private infrastructure details are committed
• Documentation is updated for user-visible or operational changes
• The PR title follows Conventional Commits