#2695: feat: migrate to pyproject and package as proper python package?

The current main branch still presents Hermes WebUI primarily as a source checkout plus a set of ad hoc launch scripts:

• python3 bootstrap.py
• ./start.sh
• ./ctl.sh start|stop|restart|status|logs
• direct top-level modules such as server.py, mcp_server.py, api/, and static/

There is no pyproject.toml, no installable Python package, and no console-script entrypoint. That makes the project harder to install, test, package, and operate like a normal Python service.

Why this is a problem

The current layout creates several avoidable issues:

• Users have to know which script is appropriate for which lifecycle path.
• Runtime behavior is split across shell scripts and Python modules.
• Environment loading and process-control behavior is duplicated across entrypoints.
• The WebUI depends heavily on being run from a source checkout.
• Packagers cannot rely on standard Python metadata or console scripts.
• Tools like uv, pipx, distro packagers, and service managers do not have a clean project boundary to target.
• Tests and docs have to account for script-specific behavior instead of a single supported command surface.

This is especially noticeable because the service already behaves like a long-running Python application, but the repository structure still looks like a collection of launch scripts.

Expected direction

Hermes WebUI should be packageable and runnable as a normal Python project.

A better command surface would likely look like a single installed command with subcommands, for example:

hermes-webui web
hermes-webui serve
hermes-webui start
hermes-webui stop
hermes-webui restart
hermes-webui status
hermes-webui logs
hermes-webui mcp

The exact command names can be discussed, but the important part is that lifecycle control should be consolidated behind one Python entrypoint instead of spread across bootstrap.py, start.sh, and ctl.sh.

Scope

This issue is about the structure on the current main branch:

• add standard Python packaging metadata
• move runtime modules into an importable package
• expose a console-script entrypoint
• consolidate lifecycle commands
• keep existing shell scripts only as compatibility shims if needed
• update README/testing/docs around the supported command surface

This should not require changing the UI or the core WebUI behavior. The goal is to make the existing service easier to install, run, test, and package.