docs(zsh-standard): require capturing a parameter before localizing it

[ss-o]

Adds zsh/parameters/capture-before-localizing to the Zsh Scripting Standard. Documentation and policy only; no behaviour change in this repository.

Why

z-shell/zi lost a working search path twice in one function for the same reason, and nothing in the standard covered it.

zi#477 removed this as dead:

local +h FPATH=$PLUGINS_DIR${fpath_elements:+:${(j.:.)fpath_elements[@]}}:$FPATH
local +h -a fpath
fpath=( $PLUGIN_DIR $fpath_elements $fpath )

It was not dead. fpath and FPATH are tied, so the scalar assignment already created the local pair populated with the caller's value, and the local +h -a fpath that follows does not reset it because the parameter is by then already local to that scope. Remove the scalar and the array declaration creates a fresh empty array, $fpath on the right-hand side expands to nothing, and the assignment silently truncates itself to $PLUGIN_DIR. Reproduced on zsh 5.9.2:

with the scalar:  count=4 : /tmp/plug /tmp/plug /aaa /bbb
without:          count=1 : /tmp/plug

Immediate autoload +X of any function the loading plug-in did not own then stopped resolving, which broke Aloxaf/fzf-tab completely. Tracked as zi#488, fixed in zi#491.

Two properties combine, and each is individually easy to misread. A second local on a parameter already local to the same scope is not a reset, so the declaration order looks redundant when it is load-bearing. And localizing a tied parameter starts it empty, so the common idiom x=( new $x ) self-truncates rather than extending. Together they produce a construct where deleting an apparently inert line changes behaviour with no error and no diagnostic.

zsh/parameters/avoid-special-name-collisions already names the path/PATH tie, but only to warn against repurposing the name. Nothing covered what the tie does to localization. The same shape applies to path, cdpath, manpath, and module_path.

What changed

The rule in .github/instructions/zsh-scripting.instructions.md, its object in lib/zsh-standard-policy.json, and both ordered inventories in scripts/validate-zsh-standard-policy.py (NORMATIVE_RULE_IDS and STARTUP_PROFILE_RULE_IDS).

The frozen consumer-parser golden moves with it, exactly as scripts/test_validate_zsh_standard_policy.py instructs when a rule is added: block count 64 to 65, startup-file membership 49 to 50, and the digest replaced with the reported actual.

Verification

python3 scripts/validate-zsh-standard-policy.py      -> passed
python3 scripts/test_validate_zsh_standard_policy.py -> Ran 99 tests, OK

Closes #602