feat(docs): user instructions and in-app help

[pskillen]

Problem

The app has many nuanced features — multi-mode channels, import/merge vs new project, format-specific export, map behaviour, zone vs scan semantics, promiscuous TG lists, and more. The UI is designed to be self-explanatory where possible, but operators still lack contextual guidance when a feature is non-obvious or when they need the full workflow spelled out.

Today, useful explanatory text lives in the README and under docs/features/ (e.g. operator lifecycle, import/export hub, map, CRUD). That content is not surfaced in the app — contributors read markdown in the repo; operators on GitHub Pages never see it unless they leave the tool.

Intended outcome

Give operators two tiers of help without turning the app into a manual-first product:

Tier	Purpose	Examples
Inline / nearby	Short context at the point of use	Field descriptions, info icons, expandable hints on Import & export, multi-mode channel editor, export picker
Long-form help	Deeper walkthroughs and workflows	Dedicated Help section or route(s) with workflow diagrams, glossary, and links to reference pages already in the app (/reference/…)

The UI should remain primary; help is additive.

First pass — embed existing docs

Reuse content we already maintain rather than writing a parallel user manual from scratch:

• README.md — what the tool is, storage model, status table
• docs/features/workflows/operator-lifecycle.md — create → edit → export workflow
• Feature docs with operator-relevant sections: import-export, map, crud, codeplug-project, persistence
• Existing in-app reference routes: band plan, Maidenhead

Approach options (pick in implementation; not prescriptive):

• Build-time or runtime markdown → React (e.g. MDX, react-markdown, or curated React pages that quote the same source files)
• Copy/adapt prose into Mantine Text / Alert / Accordion components on key routes
• Shared HelpPopover / InfoTooltip component wired from a small content manifest (route id → short + long help slug)

Content boundaries: user-facing help should stay format-agnostic where describing the internal model; link out to per-format reference (docs/reference/<format>/) or the import/export hub for wire specifics — same three-tier doc rules as contributor docs (documentation-boundaries).

Suggested scope (phased)

Phase 1 — high-traffic surfaces

• Home / new project — what “start fresh” vs import means; LocalStorage privacy note (from README)
• Import & export — merge vs new project, format picker, folder drop expectations
• Summary / project header — active codeplug, target radios (if present)
• Export flow — one project → multiple CPS formats; lossy boundary warning

Phase 2 — complex editors

• Channel edit — multi-mode tabs, mode-specific fields, callsign derivation
• Zones / TG lists / RX group lists — membership rules, promiscuous receive concept
• Map — hide from map, use location, zone colouring

Phase 3 — help hub

• /help (or nav entry) — operator lifecycle diagram, FAQ, deep links to reference tools
• Cross-links from inline help to relevant hub sections

Affected (likely)

• src/routes/ — Home, ImportExport, Summary, CRUD routes
• src/components/ — shared help primitives (popover, section description patterns)
• src/nav/ — optional Help nav item
• docs/features/ — may split or tag operator-facing excerpts vs contributor-only detail; index in docs/features/README.md

Out of scope (initial slice)

• Video tutorials or external wiki
• Context-sensitive help that blocks workflows (no forced tours)
• Duplicating full tier-3 wire tables inside the SPA — link to reference routes or format docs instead
• i18n / translations

Manual verify

1. New operator can complete import → edit → export without reading the GitHub README.
2. Inline help on Import & export explains merge vs new project.
3. Help hub (when shipped) renders operator lifecycle content consistent with operator-lifecycle.md.
4. No contributor-only jargon (adapter names, schema version) in default user-facing strings.
5. Help content readable on narrow/mobile layout.

Workflow note

Phased epic — branch from origin/main, atomic conventional commits per surface or phase, PR(s) linking Closes #. Consider docs/features/help/ progress log if work spans multiple PRs.