Realign How it works with new the hot-reload workflow

[Swiftaxe]

Goal

Realign the current How it works page so it leads with the developer experience: what your day with Serverpod looks like, not how Serverpod processes a request internally. The hot-reload dev loop is the spine.

What the page should cover

• The hot-reload dev loop as the spine: save a file, serverpod start hot reloads the server, Flutter app, generated client, and DB schema. Embedded Postgres runs as a child process of the server (no Docker needed by default).
• The load-bearing concepts: three-package project structure, code generation, Session, type safety across the stack.
• The choices the reader made at serverpod create:
  • Database: Postgres or SQLite (consistent across all run modes, not interchangeable per mode).
  • Modules: optional add-ons; link to the modules page rather than enumerating.
  • Agent skills + MCP server: an opt-in agentic dev path alongside the traditional one. Clearly mark as optional so traditional builders don't feel pushed.

Out of scope

• The request-lifecycle mermaid sequence diagram. The page should not lead with protocol-level mechanism.
• Calling out "Jetstream" by name as a brand. The page describes Serverpod as it currently is.
• A separate page for new 3.5 features (those live in the Introduction's feature list and the migration guide).
• Renaming the page. "How it works" stays.
• Production deployment specifics. Those live in deployment / migration docs.

How it connects to neighbouring pages

• Introduction answers "what is Serverpod, what's in the box". Already updated (and needs revision); lists the new dev loop.
• Get Started > Installation, Quickstart = first hands-on touch.
• Get Started > How it works (this page) = the new builder's mental model.
• Build your first app = the hands-on tour.
• Migration guide (3.5) = existing 3.4 user upgrading.