Fix outdated client, media download 403, and LID contact lookup

[lumnia-dev-ia]

Three bug fixes plus the dependency bump they depend on. No new features — I kept
this deliberately narrow so it's easy to review.

Context: I've been running this project daily and hit each of these in turn. The
first one currently stops a fresh clone from working at all.

---

1. Outdated whatsmeow — the QR code never appears

Symptom. On a fresh clone, go run main.go connects and immediately drops:

[Client/Socket ERROR] Error reading from websocket:
websocket: close 1006 (abnormal closure): unexpected EOF

No QR code, no way to pair. The underlying cause is WhatsApp rejecting the
pinned client version with Client outdated (405), which surfaces only as the
1006 close.

Fix. Bump whatsmeow to latest. That bump changes five signatures to take a
context.Context, so those call sites are updated too:

• client.Download
• sqlstore.New
• container.GetFirstDevice
• client.GetGroupInfo
• client.Store.Contacts.GetContact

This matches what several people worked out independently in #94, #136 and #153.

---

2. Media downloads always fail with HTTP 403

Symptom. download_media returns Failed to download media for every
attachment, even when the message row has complete media metadata (url,
mediaKey, sha256, length). The Python side swallows the detail; adding a log
line to the Go handler reveals download failed with status code 403.

Root cause. extractDirectPathFromURL strips the query string:

pathPart = strings.SplitN(pathPart, "?", 2)[0]

But whatsmeow builds the final URL by concatenating its own parameters with
& (download.go, DownloadMediaWithPath):

mediaURL := fmt.Sprintf("https://%s%s&hash=%s&mms-type=%s&__wa-mms=", host.Hostname, directPath, ...)

It uses & because it assumes directPath already carries the WhatsApp-signed
query (?ccb=…&oh=…&oe=…) — which is exactly what the protobuf DirectPath
contains. Stripping it produces a URL with no ? at all, so everything after
the path becomes part of the path, and the media host rejects it.

Fix. Preserve the query string.

---

3. Contact search misses LID-identified chats

Symptom. search_contacts returns nothing for people who are clearly in the
address book, and those chats show a bare 15-digit number as their name. On my
install this affected 304 of 307 one-to-one chats stored with an @lid JID.

Root cause. WhatsApp increasingly identifies chats by an opaque LID
(123456789012345@lid) rather than a phone JID. GetChatName passes that JID
straight to client.Store.Contacts.GetContact, but the contact store is keyed
by phone JID — so the lookup always misses and the code falls back to
jid.User, i.e. the raw LID.

whatsmeow already maintains the mapping (whatsmeow_lid_map; 5,439 rows on my
install) and exposes Store.GetAltJID for exactly this.

Fix. Resolve LID → phone JID before the contact lookup, and extend the
fallback chain to FullName → BusinessName → PushName → phone number. Falling
back to the phone number is still far more useful than an opaque LID.

---

Not included, but worth flagging

main() blocks on the QR channel and returns after a 3-minute timeout. That's
fine interactively, but under a service manager (launchd/systemd) it means the
process exits and gets restarted forever, with no way to see a QR code. Making
the connect path non-blocking fixes it, but it's a behavioural change rather
than a bug fix, so I left it out of this PR. Happy to open a separate one if
you're interested.

---

Testing

Applied to a clean clone of main: builds with go build, clean go vet and
gofmt. Verified against a live account — pairing works, media downloads
succeed (confirmed by opening a received PDF), and contact search returns the
right names for LID chats.