feat: add --no-ssl to serve plain HTTP despite the certificates

[luca-71]

SSL is auto-enabled whenever key.pem and cert.pem exist, and there is no way to opt out short of moving the files:

use_ssl = args.ssl or (cert_file.exists() and key_file.exists())

Since the documented setup tells you to generate those certificates in step 6, every install ends up on HTTPS with a self-signed certificate, and the browser interrupts with a warning on each visit.

That is invisible while the Vite dev server is the front door — it serves plain HTTP on 5173 and proxies to the backend, so the warning never surfaces. It becomes the whole experience the moment you serve the built frontend from the server itself, which is what an always-on local install wants.

Why plain HTTP is fine here

Browsers treat localhost as a secure context regardless of scheme, so getUserMedia and the Web Speech API work over HTTP exactly as they do over HTTPS. The certificate buys nothing on a loopback interface and costs a click every time.

The flag changes nothing for anyone who does not pass it: auto-detection still applies, and --ssl still forces HTTPS on.

Precedence

--no-ssl wins over both auto-detection and an explicit --ssl, which is the useful reading of a contradictory pair — the more specific "definitely not" beats the general "yes".

Verified

With cert.pem and key.pem present:

invocation	scheme
server.py	HTTPS
server.py --no-ssl	HTTP
server.py --ssl --no-ssl	HTTP

The startup banner announces the scheme it actually bound, so ws:// vs wss:// stays honest.

Testing

pytest tests/ gives 35 passed, 8 failed — identical to main, so no regressions. The 8 pre-existing failures are unrelated: 7 need playwright install, and test_browse_action_keywords imports ACTION_KEYWORDS, a symbol that no longer exists in server.py.

Independent of #21, #22, #23 and #24; cut from main, and a one-line behaviour change plus a flag.

🤖 Generated with Claude Code