Problem:
Flaky test:

    RUN      T1158 nvim.zip reports an incorrect archive password: 11092.84 ms FAIL

The prompt is detected only if the pty output *ends* with "password: ",
but a read may return the prompt plus following bytes.

Solution:
- Match anywhere in the output since the last password was sent. The
  buffer is cleared before each send, so won't match stale text.
- Assert on the reported message, so a failure shows what was reported.

Problem:

    FAILED   …/plugin/zip_spec.lua @ 442: nvim.zip reports an incorrect archive password
    Expected values to be equal.
    Expected:
    true
    Actual:
    false
    stack traceback:
    …/plugin/zip_spec.lua:453: in function <…/plugin/zip_spec.lua:442>

Solution:
The message is scheduled, so poll for it.

Problem:
`zipfile://{archive}::{entry}` is ambiguous: `::` is legal in both an
archive path and an entry path, so the separator cannot be identified.
Splitting at the last `::` reads archives correctly but breaks entries
that contain it, and the plugin then emits buffer names it cannot read
back.

Solution:
Address entries as `zip://{archive}/{entry}`, joining the two paths.
Resolve the split by walking components: the first one that is a regular
file is the archive, because a regular file cannot have children on disk.
Entry paths may then contain any character, and no escaping is needed.

zipPlugin.vim keeps its own scheme, so the Java ftplugin emits whichever
form matches the active plugin until the legacy package is removed.

Problem:
There is no health check. Encrypted entries cannot be read at all, since
Info-ZIP takes a password only from a terminal and `-P` would expose it
in the process arguments.

Solution:
Add `:checkhealth nvim.zip`, reporting the backend and which
implementation is handling archives. Prompt for the password on a pty,
extracting to a file so the entry's bytes stay off the terminal. Report
Info-ZIP's exit code rather than inferring a cause, so an archive using
AES is not reported as a failed decryption.