v0.9.1 — fix: keyword search aborted by MyCareersFuture timeouts

Patch: keyword search was broken by v0.9.0 — fixed

v0.9.0 introduced a regression, found and fixed by @Aneek1 in #20 within a day: MyCareersFuture's GET /v2/jobs?search= endpoint stalls or times out (HTTP 504 after ~29s) for any query not already warm in its CDN. Because the board is search-driven and multi-board search had that fetch in its path, one Singapore timeout could abort every keyword search — sdj list "java" returned zero rows from all nine boards. Unqueried browsing was unaffected.

Queries now go to POST /v2/search, which answers the same queries in about a second. The GET feed stays for unqueried browsing, where it works and carries the richer payload. Verified before merge: cold queries answer in ~1s via POST (11–29s or 504 via GET), and a cross-board sdj list "java" completes in ~4s.

Also in this patch, from re-verification against live rows:

• Agency postings now name the real employer. When isPostedOnBehalf is set, hiringCompany is the employer and postedCompany is the agency; isHideHiringEmployerName is honoured.
• apply_url is no longer null on MyCareersFuture refusals — the posting page is where applying actually happens (the portal's own flow; no external ATS links exist in sampled descriptions), so the refusal hands back that URL, as the docs always promised.
• Telecommuting now maps to hybrid, not remote — the wire lists arrangements an employer offers, which is weaker than a remote-first claim. --remote still matches; --onsite no longer discards postings that merely offer telecommuting.
• Descriptions keep the wire's own HTML in the cache (DTOs strip at render, same as JobCloud) instead of being flattened lossily at ingest.
• Docs corrected: the apply-instructions wording was JobCloud's situation copy-pasted onto a board where it isn't true, and the Singapore CV guidance no longer suggests the Letter of Consent route for Dependant's Pass holders (withdrawn May 2021; it still applies to LTVP/LTVP+ holders).

Search rows from the POST path carry only the re-stampable posting date; those rows are flagged postedAtIsBumpable so nothing mistakes a bumped date for a first-published one.

303 tests, 93% branch coverage, live lane green including the queries that previously timed out.

Full Changelog: v0.9.0...v0.9.1