Orphaned livereload process after wolt dir is manually deleted

Bug

When a wolt directory is manually deleted (e.g. `rm -rf wolts/demonightwolt`), the livereload process for that wolt keeps running and holds its assigned port. The `.state/` directory (which lives outside the wolt dir) is not cleaned up either.

This causes port collisions for newly created wolts that get assigned the same port number.

Steps to reproduce

1. Create a wolt (e.g. `demonightwolt`) — livereload starts on e.g. port 6009
2. Manually `rm -rf wolts/demonightwolt` without going through any API
3. Create a new wolt that gets assigned port 6009
4. New wolt's site fails to serve — old process is still bound to 6009

Root cause

• `stop_site()` in `sites.py` only clears the state file — it does not kill the process (no PID stored)
• `get_site_state()` checks liveness by TCP connect, so a process serving a deleted wolt's files on the port still looks alive
• When a wolt dir is deleted manually, nothing signals the server to kill its livereload process or reclaim its port

Possible fixes

• On server startup, scan `.state/site.json` files and kill + clear any whose wolt dir no longer exists
• Store PID in state file so `stop_site()` can actually kill the process
• Add a wolt deletion API endpoint that tears down the site before removing files

Start in sites.py and inspect the .state/site.json lifecycle, especially stop_site() and get_site_state(). Reproduce the issue by deleting a wolt directory manually, then verify that its livereload process is stopped, its state is cleared, and the port can be reused by a newly created wolt.