feat(amuleapi): add POST /shared/{hash}/verify (Verify Local Data) - #528

Exposes the Verify Local Data action over the REST API, following #491 which added it for the desktop clients. Reuses the EC_OP_VERIFY_LOCAL_DATA opcode as-is — no core changes.

POST /api/v0/shared/{hash}/verify (ADMIN) → 202 {"ok": true}

Up front: Verify Local Data has no mechanism to return its result to UI or EC clients. CVerifyLocalDataTask has no OnExit(), emits no notification, raises no EC event, and changes no observable file state. It collects m_corruptedMD4 / m_corruptedAICH and nothing consumes them beyond formatting them into a single log line in PrintReport(). That limitation is the same for the monolithic GUI and amulegui as it is here — it isn't something this PR introduces or works around.

So this endpoint can only honestly answer 202 (the re-hash was scheduled) and point clients at the log. amuled queues the task and replies immediately; a large file may take minutes. The verdict then appears as:

• Verify Local Data (MD4 & AICH): Result OK for <path>
• Verify Local Data (MD4 & AICH): ERRORS FOUND! <path> Failed blocks: MD4: 3,7 …

which clients read back through /logs/amule or the log SSE channel. The reference documents exactly that, and flags it for what it is: the lines are gettext-translated and carry no correlation id tying them to a request, so they are human-readable output, not a machine-parseable contract. A structured result needs a core change (task notification → EC event → typed SSE event); better as a follow-up than a parallel path bolted onto this endpoint.

Partfile guard. Incomplete partfiles are rejected with 409 partfile_unsupported — the hashing task skips partfiles outright, so accepting one would promise a report that never arrives. The guard reuses the same "genuinely incomplete" test as the path field, so a download that has finished but is still listed under /downloads remains a valid target.

Verification. Ran live against a real amuled; all 11 assertions pass, including the 409 guard (the node had an actual partfile, so that path was genuinely exercised rather than skipped):

PASS  POST /shared/{hash}/verify (no token) → 401
PASS  POST /shared/{hash}/verify (guest) → 403
PASS  POST /shared/{hash}/verify → 202
PASS  verify response .ok == true
PASS  POST /shared/{HASH}/verify (uppercase) → 202
PASS  POST /shared/{unknown}/verify → 404
PASS  unknown hash → error.code=not_found
PASS  GET /shared/{hash}/verify → 405
PASS  PATCH /shared/{hash}/verify → 405
PASS  POST /shared/{partfile}/verify → 409
PASS  partfile → error.code=partfile_unsupported

Reporting confirmed end to end as well — after the 202 the daemon logged Verify Local Data (MD4 & AICH): Result OK for …, readable back through GET /api/v0/logs/amule.

clang-format (v18, whole-file) and the clang-tidy Tier-1 + Tier-2 diff checks are both clean.