test(unload): pin the ownership contracts that already hold

[ss-o]

Measures the current unload ownership behaviour and pins the parts that already work. Test-only; no behaviour change.

What the measurement found

#113 proposes representing function, widget and bindkey ownership per load instance rather than by plug-in id. Probing each contract in an isolated shell narrows that considerably:

Contract	Today
single load then unload	works
two-plug-in widget owner chain	works
two-plug-in bindkey owner chain	works
unloading in a different order than loaded	works
repeated load of the same plug-in	broken, for function, widget and bindkey together

RESULT control single-load-unload:  pa_fn=0                       (expected 0)
RESULT repeated-load:               pa_fn=1                       (expected 0)
RESULT repeated-load-unload:        widget=[user:w1_impl]         (expected empty)
RESULT repeated-load-unload:        bind=["^X^P" zi-probe-widget] (expected undefined-key)

So the multi-plug-in chain machinery the issue calls into question is already correct: unloading the second of two plug-ins restores the first as live owner, and unloading out of order removes only the plug-in named. The defect is confined to a repeated load of the same plug-in, where all three resource kinds leak together.

That should narrow the design work the issue asks for. Per-load identity is needed to tell two loads of one plug-in apart; the chain representation across different plug-ins does not appear to need changing.

What this PR adds

tests/unload-ownership-contracts.zsh pins the four working contracts, which is what #113's own acceptance criteria ask to preserve ("keep existing single-load behavior ... compatible", "preserve correct behavior when the same plugin is loaded more than once").

The repeated-load case is deliberately absent. A test for known-broken behaviour belongs with its fix, or CI goes red for a defect nobody is fixing yet. When #113 is implemented, that case has a home here.

A correction worth recording

My first pass ran all the probes in one shell and reported out-of-order unload as broken. That was contamination: the preceding repeated-load case had already leaked the function, so the next load saw it as pre-existing and the unload legitimately left it alone. Re-run in isolation, out-of-order unload is fine. The harness now starts a fresh zsh per contract for that reason.

Full suite 23/23. Registered in zsh-n.yml, both path filters and a job.

Refs #113