fix(unload): preserve runtime ownership across repeated plugin loads

[ss-o]

Problem

Zi identifies runtime ownership by plugin ID rather than by load instance. A
second load of the same plugin can therefore overwrite or collapse the state
needed to clean up the first load.

Current examples:

• widget restoration scans later plugin loads but explicitly skips repeated
  loads of the same plugin;
• function diff state is reset on overwrite-load, so a function created by the
  first load appears pre-existing to the second and can survive the eventual
  unload; and
• bindkey and widget ownership chains cannot distinguish two instances with
  the same plugin ID.

The hook-registration cleanup added by #108 preserves its first snapshot
across overwrite-loads, which fixes that hook-specific contract without
claiming to solve the shared per-load identity model.

Impact

Repeated loads can leave functions behind or restore the wrong prior widget or
binding state. Multi-plugin replacement chains can likewise lose the
immediately preceding live owner.

Acceptance criteria

• Represent function, widget, and bindkey ownership per load instance rather
  than only by plugin ID.
• Restore or remove state belonging to the correct instance when unloading.
• Restore the immediately preceding live owner in multi-plugin chains.
• Preserve correct behavior when the same plugin is loaded more than once.
• Add focused tests for repeated same-plugin function definitions, two-plugin
  widget and bindkey chains, repeated same-plugin loads, and out-of-order
  unload.
• Keep existing single-load behavior and the hook-specific ownership contract
  from fix(unload): track and remove plugin-owned hook callbacks #108 compatible.

Next action

Define the minimal per-load identity and ownership-chain representation before
implementation, then apply it consistently to function, widget, and bindkey
records.

[ss-o]

Measured each contract in an isolated shell against current next, to narrow what the per-load-identity model actually has to solve.

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)
RESULT repeated-load-unload:        fn=1                          (expected 0)

The multi-plug-in machinery this issue calls into question is already correct. Loading a second plug-in over the same widget and binding, then unloading it, restores the first plug-in as the live owner; unloading out of order removes only the plug-in named and leaves the other intact. The defect is confined to a repeated load of the same plug-in, where the function, the widget and the key binding all leak together.

That suggests the design work is narrower than the acceptance criteria imply: per-load identity is needed to tell two loads of one plug-in apart, but the ownership-chain representation across different plug-ins does not appear to need changing. Worth confirming before the model is designed, since it removes the largest part of the proposed scope.

#504 pins the four working contracts so the eventual change cannot quietly break them, which is what the criteria here ask to preserve. The repeated-load case is deliberately not asserted there; it belongs with the fix.

One correction on method, in case anyone repeats this: running all the probes in a single shell reports out-of-order unload as broken. That is contamination, not a defect. The preceding repeated-load case leaks the function, so the next load sees it as pre-existing and the unload correctly leaves it alone. Each case needs its own shell.