pi-permission-system: brace expansion hides a parent traversal from the bash path projection

[gotgenes]

Package

pi-permission-system

What happened?

Bash brace expansion can produce a parent-traversal path the bash path projection never sees.
cat {..,y}/z makes bash read ../z and y/z, but the token reaches the classifiers as the literal {..,y}/z.
The resolver resolves that literal lexically against the effective working directory, where {..,y} is a single segment, so the path stays inside the cwd and nothing is flagged.

I measured this at 60c22b0a with a disposable spike through the real BashProgram (cwd /home/user/work):

Command	externalAccesses()
cat {..,y}/z	[]
cd ~/x && cat {..,y}/z	[…, "/home/user/work/{..,y}/z"]

The second row is flagged only because the effective base is unknown after cd ~/x and today's classifier accepts any token that contains .. as a substring.
Issue #859 narrows that to a whole .. segment (so git revision ranges like HEAD..origin/main stop raising external_directory asks), and the unknown-base row will then return [] as well.
So both rows will be unflagged, and brace expansion becomes a gap that nothing records.

Expected behavior

A token whose brace expansion yields a .. segment should reach the external_directory gate.
The simplest options I can see:

• Treat an unexpanded brace-expansion token ({a,b}, {1..3}) conservatively, the way ADR 0009 handles an unknown base.
• Expand the brace set at token collection, the same way $HOME/$PWD are resolved in shell-variable-expansion.ts, and classify each expansion.
• Record it as an accepted residual in ADR 0009's "What the projection deliberately omits" list, next to "Glob expansion" (pi-permission-system: gate a glob token by its expansions, not only its literal text #822).

Additional context

Found while planning #859.
The {..,y} form turned up in no command of an 8360-command local review-log corpus, so this is a reachability gap rather than an observed one.