Add documentation for deploying a Topcoat application

[JuanMarchetto]

The README roadmap lists "Docs for how to deploy Topcoat" as unchecked, and nothing in crates/*/docs/ covers it. I deployed a Topcoat application this week, and the gap cost more time than any other part of the build.

The things a guide would need to cover, from what I hit:

• Building the release binary and what has to travel with it.
• topcoat asset bundle, which defaults to the dev profile, so the bundle a release binary needs is not the one the documented command produces. A missing asset panics a worker thread per request at render time, and the client sees an empty reply rather than a 500.
• Asset ids are minted from the OUT_DIR path for generated assets, so a bundle built in one directory does not serve a binary built in another. That rules out building the bundle in CI and shipping it, which is the first thing most people will try.
• HOST and PORT, since Topcoat.toml is a marker file and configures nothing.
• The router terminates no TLS, so a reverse proxy is required, and serve.rs has a Unix socket listener that suits that setup.
• Persisting the cookie Key across restarts. Generating it per boot logs every session out on deploy.
• Shard endpoint URLs come from Uuid::new_v4() at macro expansion, so they change on every build. An open tab polling a shard gets a 404 after a restart and the widget goes silent. A rolling deploy needs this said out loud.

I have the material for all of it, measured on a real deployment rather than a hello world. Would a page under crates/topcoat/docs/ be the right home, or does this belong in the getting-started flow?

I would be happy to write it.

[AmeinEskinder]

I went digging at the shard bullet in your list, and I think it belongs in its own issue rather than in the guide.

Three consecutive builds of examples/shard, with nothing changed but a comment to force the recompile:

eef902d7-03b6-4c18-9835-ce7bd2c730b8
62e1d4bd-1cb9-4a4d-a021-a0938ce2fef3
aed3c0c7-5051-4b8d-84fc-347491b5fe72

Against the running server the current id is the one in the page HTML, and both of the older URLs POST to 404, so a tab that was open across a deploy just goes quiet with nothing in the console worth noticing.

Two things I hadn't expected. #[procedure] has it too, procedure.rs:123 is the same Uuid::new_v4() at expansion time, so a stale tab's button click 404s the same way. And the third id above only appeared because topcoat asset bundle compiles the crate itself, which means the bundling step can mint fresh ids partway through the very deploy sequence the guide would be describing.

There's already a pattern for this in the tree: AssetId::new hashes crate name, source file and path, and something similar over crate plus module path plus ident would stay opaque while surviving a rebuild.

One argument the other way, which matters more after #251. A fresh id per build means a URL someone learned once stops working at the next deploy. Making them deterministic makes that URL permanent. It isn't really protection, since the page hands the id out to anyone who loads it, but it's worth saying out loud rather than leaving for a reviewer to spot.

It's your find, so I'd rather you filed it, but happy to write it up if you'd prefer.