fix: lazy keys in mode "!", reload, named update of a cond = false plugin, and main detection - #55

After a declined install `:ZPack! build` reported the plugin as not
registered, then ran its build with a nil plugin and counted it.

`:ZPack update <name>` and `:ZPack restore <name>` checked the name against
the tab-completion list, which leaves out plugins `cond` keeps unloaded, and
answered "not found in spec" for one the bulk update covers. They now ask the
registry.

`:ZPack reload` only looked at `package.loaded` keys under the plugin's
`main`, so `telescope._extensions.x` and other second namespaces stayed
stale. As in lazy.nvim, every module with a file under the plugin's `lua/`
is dropped.

`:ZPack reload` of a pending lazy plugin ran its teardown hook, which could
pull the plugin in through a `require` and configure it twice. As in
lazy.nvim, the hook runs only for a loaded plugin.

A plugin whose `lua/` holds one top-level module not named like it, as
none-ls.nvim's `null-ls`, got a "Could not determine main module" warning
and no `setup()`. lazy.nvim's get_main falls back to that module, so
LazyVim's none-ls extra relies on it.

setup() runs once, and state.lua creates LazyBuildPack and DeletePack
cleared; their only writers run after these lines.

register_all hands them over sorted with the same comparator, a total
order, and nothing in between changes a priority or an import order.

entry_to_info spelled the mid-install shape itself, which left
derive_status's own "installing" branch unreachable.

The KeySpec reference said `(function, required)`, against the type, the
code and `:h zpack-Spec.keys`.

It listed a `rev` field the API doesn't return, and lacked the
"installing" status and its nil `path`.

The vimdoc's Spec.build gave only string and function, and spec.md said
shell builds run via $SHELL, which hooks.lua avoids on purpose.

The reload and dev passages presented `dev = true` plus `:ZPack reload` as
the loop for iterating on a local checkout. `vim.pack` clones the checkout
into its data dir, so an edit reaches Neovim only after a commit and
`:ZPack update <name>`.

…efore `config`

`:ZPack update` and `:ZPack delete` complete the registered names, as the
restore entry already says, not every installed plugin. `plugin.main` is
resolved before `config` is called and is nil inside `opts` functions.

Several entries in the help file and the migration notes had grown into
single paragraphs listing every edge case. Split them into a short
description followed by lists, lead each command and field with what it
does, and say "as in lazy.nvim" in a sentence where a bare tag stood.
No behaviour is described differently.