Add Wireless PRO support, and wait for the erase to finish

[lgnap]

Follows up on #2, where I reported that the Wireless PRO answers the same
delete command. It does, unchanged — so this adds it, plus two fixes that the
second transmitter forced out into the open.

Tested on two Wireless PRO transmitters, one connected directly and one docked
in the charging case. Both erased. I do not have an Interview PRO, so that path
is unchanged by design and untested by me.

Both Wireless PRO transmitters share PID 0x0056

Interview PRO gives its two units distinct PIDs, so trying each PID in turn
reaches both. Wireless PRO does not: hid_open(vid, pid, NULL) returns
whichever transmitter enumerated first, and the other is unreachable.

Devices are now enumerated with hid_enumerate() and opened with
hid_open_path(). krode delete still erases everything connected; passing a
serial targets one transmitter, and krode list shows what is there.

Node numbers are not stable

Opening by path matters beyond addressing. Replugging the charging case
swapped the two transmitters' hidraw numbers:

before:  hidraw10 = 800A92D6      hidraw12 = 800AF63E
after:   hidraw10 = 800AF63E      hidraw12 = 800A92D6

Resolving the path in the same enumeration that produced the serial keeps the
two consistent, so a targeted delete cannot land on the wrong microphone.

The reply is progress, not a status code

This one is a real bug in the current behaviour, not just a Wireless PRO
concern. The device does not answer once — it streams:

02 4A 41 00     0 %
02 4A 41 05     5 %
   ...
02 4A 41 64   100 %

Byte [3] is a percentage. Reading only the first reply prints
Done. Recordings deleted. (status: 0) while the erase is still running.
krode now waits for 100, and shows progress on a terminal — quietly when
redirected, so logs do not fill with percents.

Also documented

• The transmitter re-enumerates afterwards and its volume comes back without
  a filesystem until a replug. I initially thought it recovered on its own;
  it does not, and someone following the old procedure would wait indefinitely.
• The HID serial is the FAT volume UUID of that transmitter's storage, which is
  a practical way to tell two identical transmitters apart: mount the volume,
  read a filename.

Notes

• Builds clean with -Wall -Wextra, no new dependencies.
• The committed krode binary is left untouched — this changes only krode.c
  and README.md.
• The udev rule already matches the whole vendor, so it needed no change.

Happy to adjust anything, including splitting the progress fix out if you would
rather take it separately from the device support.

[lgnap]

I should have looked at the open PRs before sending this — #1 got here three
months ahead of me and already adds Wireless PRO support, with the same
enumerate-and-open-by-path approach this uses. Apologies for the noise,
@zinic. Your PR should land, not this one.

It is also better than mine in places: distinguishing found from failed,
returning an error on an unexpected response instead of 0, and dropping the
committed binary into .gitignore.

What does not overlap is the progress handling, and I think that one is
worth keeping regardless of which device support lands:

The device does not answer once. It streams 02 4A 41 <percent>, stepping to
100. Reading a single reply — which both the current code and #1 do — prints
Done. Recordings deleted. (status: 0) while the erase is still running. That
affects the Interview PRO too, not just the Wireless PRO; the "status 100" in
the README is the device reporting 100 % complete, not a success constant.

So: happy to close this and reopen a small PR containing only the progress fix,
rebased on top of #1 once it is merged. That would leave a two-line-ish change
instead of a competing rewrite. @LinuxRenaissance, tell me which you prefer and
I will do that — or close this outright if you would rather take it as an issue.

The other findings from #2 (replug needed before the volume returns, hidraw
numbers swapping across a replug, and the HID serial being the FAT volume UUID)
are documentation rather than code, and can go wherever you find them useful.

[lgnap]

Closing in favour of #1, which does the device support and got here first. Reopening a minimal PR with only the progress fix, which #1 does not cover and which affects the Interview PRO as well.