docs: lean-build behavior + nav placement + fix stale prod plugin list

- PLUGINS.md: new 'Lean per-site builds' section (backend/frontend/DB layers,
  manifest-less core frontends always ship, menus gated to staged routes).
- PLUGIN-HOOKS.md: get_navigation_items sidebar placement (position ranges ->
  Assets/Information sections, section override, icon key).
- DEPLOY-WINDOWS-IIS.md: fix stale plugin list (equipment -> machines, complete
  the bundled set), add apply-profile + prune-schema flow.

docs/PLUGINS.md

@@ -67,6 +67,37 @@ For sister-site plugins (per [ADR-003](adr/ADR-003-plugin-distribution.md)):
 - Plugin manifest declares `core_version` range matching the framework version they target
 - Plugin readme explains: what it tracks, who maintains it, where to file issues
 
+## Lean per-site builds
+
+A site ships only the plugins it chose; a site that never wants printedparts /
+usb / network never carries that code (see
+[ADR-013](adr/ADR-013-plugin-catalog-and-lean-builds.md) and
+[ADR-014](adr/ADR-014-schema-lean-per-site.md)). Three layers make a build lean:
+
+- **Backend code** - `scripts/build-site.sh <profile>` stages `shopdb/core` plus
+  only the chosen plugins' directories (and their hard-dependency closure). A
+  plugin a site did not choose is absent from the backend tree.
+- **Frontend code** - `SITE_PLUGINS=machines,printers npm run build` (via
+  `scripts/stage-frontend.mjs`) stages only those plugins' `frontend/` dirs and
+  codegens the route table. **Exception:** a `plugins/<name>/frontend/` dir with
+  **no `manifest.json`** is a CORE feature (e.g. `applications`), not a per-site
+  plugin, and is ALWAYS staged regardless of `SITE_PLUGINS` - otherwise a lean
+  build would lose a core page.
+- **Database** - the shared core Alembic baseline creates every plugin's tables,
+  so a lean site provisions them and then drops the ones it does not use with
+  `flask plugin prune-schema` (ADR-014). Run it once at provisioning, after
+  `flask db upgrade` and `flask plugin upgrade-all`; see
+  [DEPLOY.md](DEPLOY.md).
+
+**Menus follow the build, not a plugin flag.** The sidebar nav, the settings
+rail, and the Displays links all gate on whether the target route was actually
+staged into this build (the router's own route table), not on a registry
+"enabled" flag. So a lean site never shows a menu entry that dead-ends on a
+blank page - an omitted plugin's nav item, settings cards, and kiosk links all
+disappear together. Shopfloor Dashboard is a core view but is gated on the
+notifications plugin (its only data source), so it drops when notifications is
+not in the build.
+
 ## Naming policy
 
 Plugin names follow the framework's naming convention (lowercase concatenated, no underscores or dashes; full words preferred over acronyms). See [CONTRIBUTING.md](../CONTRIBUTING.md). Plugin name collisions across sites are not enforced; the convention recommends prefixing site-specific plugins with the site code (e.g., `wjsf-shippingstation`) when there is risk of overlap.