Enrich the download-detail endpoint and add a shared-file detail endpoint #417

Summary

Two gaps in the amuleapi REST API around single-file information:

1. GET /api/v0/downloads/{hash} exposes only a subset of what the aMule desktop File
   Details dialog (CFileDetailDialog) shows.
2. There is no single-file endpoint for shared files at all — /api/v0/shared/{hash}
   only accepts PATCH, and GET /api/v0/shared returns just a lean list (7 of the 12
   columns of the desktop shared-files table).

This issue (a) wires the missing download-detail fields through, and (b) adds a new
GET /api/v0/shared/{hash} detail endpoint that returns all available info for a
shared file. GET /shared (the list) is left unchanged.

Most values are already shipped by amuled over EC — the refresher just drops them; the
rest are trivially computed in the amuleapi backend.

Effort: webapi-only. No amuled or EC-protocol changes.

Part A — GET /downloads/{hash} detail fields

Extend FileSnapshot::DownloadSide (src/webapi/State.h:96), decode the tags in
src/webapi/Refresher.cpp (MergeDownloadTags), and emit the fields in
WriteDownloadObject (src/webapi/Api.cpp:1595). All download-side tags are already
emitted by CEC_PartFile_Tag (src/ECSpecialCoreTags.cpp:151-212).

New fields (inside the download object unless noted):

remaining_time (computed in the backend)

The desktop getTimeRemaining() (src/PartFile.cpp:4423) computes ETA as
(size - size_done) / (speed), returning -1 when the speed is ~0. There is no EC tag
for it, but amuleapi already has size, size_done and speed_bps in the snapshot, so it
computes remaining_time server-side — no amuled/EC change needed.

File Details coverage notes

• The "Filepart-Count" line in the dialog shows PartCount (HashCount). part_count is
  covered; hash_count (GetHashCount()) has no standalone EC tag — a minor, derivable
  gap, not blocking.
• The dialog's "Cleanup" button is a pure client-side filename-beautifier heuristic
  (src/FileDetailDialog.cpp:415-505) — no API data; a client implements it locally.
• These fields back the "General", "Transfer" and "Intelligent Corruption Handling" boxes
  of CFileDetailDialog (src/FileDetailDialog.cpp:151-192).

Part B — new GET /shared/{hash} (shared-file detail)

GET /shared (the list) stays exactly as it is. Add a new detail endpoint that returns
all available info for a single shared file — the goal is one call that gives a client
everything about a file.

• Routing: /api/v0/shared/{hash} currently maps only PATCH → HandleSharedPatch
  (src/webapi/Api.cpp:851-855). Add a GET branch → a new HandleSharedDetail +
  WriteSharedDetailObject, mirroring the download detail path (Api.cpp:2204 /
  HandleDownloadDetail).
• Base fields: everything WriteSharedObject (Api.cpp:1701) already emits —
  hash, name, ed2k_link, size, priority, priority_auto, complete_sources, xfer{session,total}, requests{session,total}, accepts{session,total}.
• Plus the following detail fields (the shared-files table gaps + shared-applicable
  identity fields):

The "Obtained Parts" availability-bar column is intentionally excluded — it is the only
shared-table column that would need a new EC tag, and it is ~100% for complete shared files.

Acceptance criteria

• GET /downloads/{hash} returns all Part-A fields with correct values for an active
  download; remaining_time is -1 when paused/stalled.
• GET /shared/{hash} exists (new) and returns every GET /shared field plus the
  Part-B detail fields for a shared file; share_ratio is 0 when size == 0; path is
  "[PartFile]" for a shared partfile.
• GET /shared (the list) is unchanged.
• No regressions in the existing download-list / download-detail / shared-list payloads.