0.2.6

• Fix: recover-vpn didn't actually fix a stuck forwarded port in practice - confirmed live against a real AirVPN session stuck for days. synovpnc reconnect, the CLI command it used to redial the tunnel, reports success (Reconnect [...] ... done) without actually tearing down and re-establishing the connection whenever DSM still considers it up; the OpenVPN process PID and uptime never changed. recover-vpn now drives the same DSM web API Control Panel → VPN's own Connect/Disconnect buttons use (SYNO.Core.Network.VPN) - looking up the profile's internal id by name across every VPN Center connection type, then explicitly disconnecting and reconnecting - which is what genuinely redials the tunnel. DSM_VPN_PROTOCOL is no longer needed for this (kept for backward compatibility).
• New: every recover-vpn step is now also written to var/shield.log, so a run triggered from Task Scheduler shows up in the web UI's log panel - previously it only echoed to stdout, visible solely in that task's own Task Scheduler run result.
• New: the Transmission port-test check now runs from the reconcile daemon itself, once per PORT_TEST_INTERVAL_SEC, instead of only when Uptime Kuma push monitoring is configured. A successful RPC push only means "Transmission was told to listen on this port" - it says nothing about whether your VPN provider actually forwards it, which is exactly what stayed invisible in the all-green dashboard case diagnosed live on this project (tunnel up, RPC push succeeding, port genuinely closed). The web UI's Forwarded Port chip now reflects the real port-test result, and turns up a dedicated alert (with a link to run recover-vpn when configured) when the port tests closed despite a successful push.
• Refactor: the port-test logic moved from guard-push into the shared _common.sh (port_test()), reused by both reconcile and the Kuma push daemon against the same cache file, so there's a single always-current source of truth regardless of which caller last refreshed it.