fix(unload): repeated-load takeover misses linked keymaps and duplicates keymap records

[ss-o]

Environment

Zsh 5.9.2, Linux; zi next plus #582 at 2832076. Found by the third independent review of that pull request (#582 (review)).

Minimal reproduction

Each case runs in a clean zsh -f with an isolated HOME, XDG_* and ZDOTDIR. p, tv, te, r and n are local plugin directories.

1. Linked main keymap. p runs bindkey '^X^P' zi-repeat-widget, and tv runs bindkey -M viins '^X^P' end-of-line:

bindkey -v                     # main is now linked to viins
zi load "$p"; zi load "$tv"; zi load "$p"
zi unload "$p"
bindkey -M viins '^X^P'        # tv is still loaded

The same happens with bindkey -e and a plugin that binds the key with -M emacs. An EDITOR containing vi links main to viins at startup, so case 1 also applies without an explicit bindkey -v.

2. Duplicate keymap records. n runs bindkey -N nmap emacs and bindkey -M nmap '^X^P' end-of-line:

zi load "$n"; zi load "$n"
zi unload "$n"

3. A change made without zi records. p defines shared_fn, and r defines the same function:

zi load "$p"; unfunction shared_fn
zi light-mode for "$r"
zi load "$p"; zi unload "$p"
(( ${+functions[shared_fn]} ))   # r is still loaded

Actual behavior

1. Both main and viins end up with "^X^P" undefined-key while tv is still loaded. On next (75d722c), both keep end-of-line. With a single load of p, the result is the same on both branches.
2. The end state is correct, but unload prints .zi-unload:bindkey:90: no such keymap 'nmap' and .zi-unload:bindkey:113: no such keymap 'nmap', and repeats the Deleting lines. The repeated load keeps the -N record twice. On next, each line appears once and there are no errors.
3. shared_fn is removed (0); on next it stays (1). A single load of p gives 0 on both branches. The pull request's Known limits section names only a user rebinding a key or redefining a widget, not functions or plugins loaded in light mode.

Expected behavior

1. A binding through the keymap main is linked to counts as a change of the same binding. The takeover check resolves the link when it builds the identity, so a repeated load keeps next's behaviour. A linked-taken scenario in tests/repeated-load-ownership.zsh pins this.
2. A repeated load does not append a record whose text it already holds, so unload replays each record once.
3. The Known limits text says the limit covers any change made without zi records (by the user, or by a plugin loaded in light mode), functions included. Whether to detect these changes stays with fix(unload): preserve runtime ownership across repeated plugin loads #113.

Refs #113.

[ss-o]

Project 28 triage. Values set on this new issue:

• Status: Todo. Scope agreed by the maintainer as the follow-up to the fix(unload): keep ownership across repeated loads of one plugin #582 round-3 review; ready to start once fix(unload): keep ownership across repeated loads of one plugin #582 is merged.
• Item Type: Bug. Incorrect unload behaviour (one case worse than next) and spurious unload errors.
• Impact: Low. Needs a plugin loaded twice plus a second plugin using a linked keymap name between the loads; the error case changes no state.
• Effort: S. One identity change and one record dedupe in zi.zsh, plus a test scenario and a body sentence.
• Priority: P3 - Low. P3 - Low: narrow trigger, no data loss, no deadline.
• Workstream: Human delivery. Ordinary delivery work.

Labels type:bug and area:zi were set at filing.

Next action: after #582 merges, resolve the linked keymap in the takeover identity with a linked-taken scenario failing first, dedupe repeated records, and widen the Known limits text.

[ss-o]

Status: In Progress. Fix is in #584 (head 51e702b, into next).

• Linked keymaps: the takeover check now resolves the keymap main is linked to, so bindkey -v / bindkey -e with a -M viins / -M emacs takeover keeps next's behaviour. Pinned by the linked-taken and linked-taken-emacs scenarios.
• Duplicate records: a repeated load no longer appends a bindkey or widget-delete record it already holds, so unload replays each once. Pinned by keymap-twice, plus hook-twice for the same replay with a zle-line-init hook (no such widget), found while reproducing this.
• Known limits: widened in the code comment, the test header and the PR body.

Next action: CI on the head, review of record on 51e702b, then the merge decision. As #584 targets next, this issue stays open until next is promoted to main.