Issue Title: [Bug] False-positive port detection logic in axs wrapper script on Node v24

[TurinFohlen]

Description:
I have identified a specific bug in the axs startup sequence. The script incorrectly flags port 8767 as "in use" even when it is completely free. This appears to be an issue with how the wrapper script (or its dependency for port checking) interacts with the network stack on Android/Termux using Node v24.
​The Evidence of Logic Failure:
​Standard Tools: lsof, netstat, and ss all confirm port 8767 is NOT in use.
​The "Bypass" Proof: By manually patching the axs script to check a different port (e.g., 8888) instead of 8767, the server launches successfully and binds to the original port 8767 without any issues.
​Workaround used to confirm the bug:

~ $  sed -i 's/8767/8888/g' $(which axs)

After this command, axs checks port 8888, finds it clear, and then proceeds to start the server which successfully listens on 127.0.0.1:8767.
​Root Cause Analysis:
The check_port or similar IP/Port detection function used in the axs source code is giving a false-positive EADDRINUSE error. This could be due to:
​Incompatibility with Node v24's socket implementation on Android.
​Incorrect handling of IPv4 vs IPv6 loopback addresses.
​A faulty dependency used for port scanning within the axs package.
​Requested Fix:
Please update the startup logic to either:
​Remove the pre-flight port check and allow the server to throw a real error if binding fails.
​Update the port-checking logic to be compatible with modern Node.js versions on Termux.
Supplement:
The Absurdity of the Current Logic
​To highlight how ridiculous this bug is, here is the paradox I discovered:
​The Lie: The axs script refuses to start because it "thinks" port 8767 is busy.
​The Trick: I manually patched the script (using sed) to make it check port 8888 instead.
​The Result: The script says: "Okay, port 8888 is free, you're good to go!"
​The Reality: The script then proceeds to launch the server, which successfully binds to and runs on the original port 8767 without any issues.
​Conclusion:

The pre-flight check and the actual server binding are completely disconnected. The check is failing due to a false positive, while the server itself is perfectly capable of using the port. This confirms that the port-checking mechanism is not just redundant, but actively preventing the app from working.