refactor(unload): chain-aware restore for per-load ownership records

[ss-o]

Current limitation

Zi keeps runtime ownership records (functions, widgets, key bindings) per plugin ID and restores each plugin from its own snapshot on unload. #582 (squash 8bbd62c on next) fixed the same-plugin part of #113: a repeated load of one plugin keeps its records when no other plugin took a recorded widget or binding over in between. Three cases remain, all recorded on #113:

• Interleaved takeover: another plugin takes the widget or binding over between two loads of the same plugin (zi load p; zi load q; zi load p). Zi then falls back to resetting the records, as next did before fix(unload): keep ownership across repeated loads of one plugin #582, so unloading in either order can restore the wrong prior owner or leave a widget pointing at a deleted function. Measured during fix(unload): keep ownership across repeated loads of one plugin #582: unloading q then p removed p's live widget and binding when records were relinked, and without relinking the order p then q left a widget bound to a deleted function.
• Per-load-instance records: fix(unload): preserve runtime ownership across repeated plugin loads #113's first acceptance criterion asks for function, widget and bindkey ownership per load instance rather than per plugin ID. fix(unload): keep ownership across repeated loads of one plugin #582 did not introduce load instances.
• Changes made without zi records between two loads (the user rebinds the key or redefines the widget, or a light-mode plugin does): the second load overwrites them and unload restores the state from before the first load (fix(unload): preserve runtime ownership across repeated plugin loads #113 (comment)).

The root cause is that unload restores from per-plugin snapshots, not from an ownership chain, so it cannot tell who held a widget or binding immediately before the instance being removed.

Proposed improvement

Design, before any code, a chain-aware restore:

1. A minimal per-load identity (for example a load counter stored with each record) for function, widget and bindkey records.
2. An ownership chain per widget and per (keymap, key) binding: an ordered list of (load instance, previous value) entries, so unloading any instance in any order restores the immediately preceding live owner and relinks the next one.
3. Detection of changes made without records: compare the recorded previous value with the live value at load and unload, and decide whether the chain treats such a change as a new owner or stops restoring.
4. Compatibility: single-load behaviour, the hook ownership contract from fix(unload): track and remove plugin-owned hook callbacks #108, and the same-plugin behaviour pinned by tests/repeated-load-ownership.zsh from fix(unload): keep ownership across repeated loads of one plugin #582 stay unchanged; the public-contract manifest is checked for output or ordering changes.

Deliverable of this issue: a written decision (comment or ADR draft) with the data model, the unload algorithm, the test matrix (two-plugin widget and bindkey chains, interleaved same-plugin loads, out-of-order unload, linked main keymaps from #583, user change between loads) and an effort estimate, for the maintainer to approve before implementation. #113's remaining acceptance criteria move here; #113 can close once this design is delivered and implemented, or once the maintainer descopes it.

Self-service

• I would be willing to implement this improvement.

Project policies

• I have read the contribution guidelines.
• I agree to follow the Code of Conduct.

[ss-o]

Project 28 triage. Values set on this new issue:

• Status Triage: a design that needs the maintainer's agreement before implementation.
• Item Type Bug, Impact Medium, Priority P2 - Medium, Workstream Human delivery: the same values as fix(unload): preserve runtime ownership across repeated plugin loads #113, whose remaining acceptance criteria this issue takes over by maintainer decision.
• Effort L: a data-model and unload-algorithm change across function, widget and bindkey records, plus a two-plugin test matrix.
• Labels type:maintenance, area:zi, status:triage (from the issue form).

Relation: this issue now blocks #113 (native link). Evidence, from #113 (comment): "the remaining scope of this issue moves to #585, which designs a chain-aware unload restore before any implementation".

Next action: write the design decision described above for the maintainer to approve. No code before that approval.