Fixes two independent bugs that between them made amipkg install fail on any
machine with a current AmiSSL — while iBrowse and LumiFTP worked fine, which made
it look like amipkg's own fault rather than a version handshake. It was both.
1. AmiSSL version pinning
amipkg asked for AMISSL_V11x, which the SDK header defines as AMISSL_V110d —
the AmiSSL v4.0-era OpenSSL 1.1 API. AmiSSL 5.2x ships only the OpenSSL 3.x
line (amissl_v5 / amissl_v362), so InitAmiSSLMaster() accepted the request
and OpenAmiSSL() then found no 1.1 implementation to hand back. A current,
healthy AmiSSL failed with "couldn't open AmiSSL", and the neighbouring branch
would have reported "too old" when the truth was the opposite.
Pinning any single level is wrong in one direction or the other:
AMISSL_CURRENT_VERSION is baked in at build time and rejects good older
installs; AMISSL_V11x rejects good newer ones. amipkg now walks a list from
newest to oldest and takes the first that both initialises and opens.
Diagnosed against two machines: an A4000 with amisslmaster 5.22 +
amissl_v111m worked, a PiStorm/Emu68 box with 5.27 + amissl_v362/amissl_v5
did not. The deciding factor was which implementation library was installed,
not the AmiSSL version.
2. Signed download URLs were truncated
With TLS working, GitHub release downloads then failed as HTTP 618 — not a real
status, just a garbled parse. GitHub's release-asset redirect carries a signature
in the query string and runs to about 915 characters; path[512],
redirect[512] and req[768] cut it mid-signature, so the request went out
malformed. All are now sized from AMIPKG_URL_MAX (2048).
This one was hidden behind the first — it would have hit every GitHub-hosted
package the moment AmiSSL was fixed.
Verified end to end on both machines: fetch, redirect, SHA-256 verify, install.