fix(packaging): declare openssl as an AUR dependency

[ShortArrow]

#179 shipped depends=('glibc' 'libgcc' 'libstdc++' 'icu') and an explicit comment saying OpenSSL was not required. That was wrong, and the way it was wrong is worth recording: the strace behind it covered --version, doctor, and three --help invocations — paths that never touch cryptography. Re-running the trace over paths that do the actual work says otherwise.

command	libssl/libcrypto	libz
ivicli --version	—	—
ivicli api start (plain)	—	—
ivicli server start …	—	—
ivicli visa scan	yes	yes
ivicli api start --tls-self-signed	yes	yes

visa scan is not an edge case, so this would have hit an Arch user on a system that happened to lack openssl.

Proven by removal rather than by reading the trace, the same way icu was:

# pacman -Rdd openssl && ivicli visa scan
No usable version of libssl was found
timeout: the monitored command dumped core

# ivicli --version        (still fine — it never reaches crypto)
0.3.1+8801f2e…

zlib is deliberately not declared. It is loaded on the same paths, but by libssl rather than by the CLI — removing zlib makes libssl itself unloadable — and Arch's openssl already depends on it. namcap confirms the judgement from the other side: declaring it earns Dependency included, but may not be needed ('zlib').

namcap now reports five expected warnings instead of three: it flags openssl exactly as it flags icu, because it reads the ELF and both arrive through dlopen. packaging/aur/README.md lists all five with the two removal commands that check the claim, so the next maintainer verifies rather than trusts the tool that is blind here.

Verified end to end after the change: makepkg builds, .PKGINFO carries the five depends, and on archlinux:base with no dotnet on PATH the installed package runs --version and completes visa scan. .SRCINFO regenerated from the edited PKGBUILD.