fix(date): compute expiry dates without GNU or BSD date

[rvalitov]

Problem

The codebase builds expiry dates with date -d ... || date -r ... || ... chains. None of those branches works on Alpine:

• date -d is GNU-only
• date -r <epoch> is BSD-only — busybox's -r reads the timestamp of a file
• date -v+1d is BSD-only

So on Alpine every fallback failed, with these results:

Site	Effect on Alpine
run_guest	empty expiry, so guest <label> 24h and the onboarding wizard failed outright
secret_extend, secret_bulk_extend	no new date computable; last resort was python3, which Alpine does not ship
voucher_redeem	fell back to now, so a voucher expired the instant it was redeemed instead of after its stated duration
secret_check_quota_resets	fell back to a hardcoded 31, firing the monthly reset on the wrong day for every month shorter than 31 days

Fix

_epoch_to_date() uses bash's printf %()T, which does the conversion in-process and needs no external command at all. The date branches are kept only as a fallback for bash builds without it. _last_day_of_month() handles the calendar arithmetic, with proper leap-year rules.

Display sites keep rendering local time — only the UTC expiry maths changed, so no timezone behaviour changes. Format strings still carry a leading + at the call sites (the date convention); the helper strips it for printf and restores it for the fallbacks.

Testing

New tests/test_date_portability.sh puts a busybox-style date on PATH — one that still formats normally but rejects -d @epoch, -d "+N days", -r and -v, which is precisely the busybox gap. It asserts expiries are not just well-formed but land on the correct calendar day, and covers leap years including the 1900/2000 century cases.

Verified on Alpine 3.20: tests/test_guest.sh goes from 6 failures to 0. This fix is not required and does not change anything on the following tested machines: Debian 12, Ubuntu 22.04/24.04 and Fedora 41.