docs: trace one observation from a form to Synkronus and back

[Mishael-2584]

The small adventure

Pick one imaginary observation, perhaps a tree measured in the rain, a household
visit, or a water-point inspection. Then follow it through ODE:

1. Formplayer renders the JSON form.
2. The Formulus bridge receives the completed data.
3. Formulus stores it locally while offline.
4. Sync pushes it to Synkronus.
5. Another client can pull or export it.

Turn that journey into a short contributor-facing code map. This is a
documentation issue, but not a scavenger hunt with no finish line: every step
must point to real code and a real test.

Where to start

• Root AGENTS.md
• formulus-formplayer/AGENTS.md
• formulus/AGENTS.md
• synkronus/AGENTS.md
• formulus-formplayer/src/services/FormulusInterface.ts
• formulus/src/webview/FormulusMessageHandlers.ts
• formulus/src/database/repositories/
• formulus/src/services/SyncService.ts and formulus/src/sync/
• synkronus/internal/handlers/sync.go
• synkronus/pkg/sync/service.go

These are trailheads, not a demand to document every file in each directory.

Deliverable

Add one concise Markdown page under docs/ with:

• a Mermaid sequence diagram of the happy path;
• a table with roughly 6-10 steps, naming the responsible project and linking
  to the most relevant source symbol/file;
• one paragraph explaining what changes when the device is offline;
• one paragraph explaining that attachments travel through a related but
  separate pipeline;
• a "prove it to yourself" section linking to 3-5 existing tests that exercise
  important parts of the journey;
• a short list of intentional simplifications, such as conflict handling or
  repository-reset recovery, so readers do not mistake the map for a complete
  protocol specification.

Aim for about 600-900 words. This should be a trail map, not another architecture
bible.

Guardrails

• Describe what the current code does; do not design a new sync protocol.
• Prefer links to source and tests over copying large code snippets.
• Use "observation," "form type," and other project terms consistently.
• Do not claim that observation JSON contains attachment binaries. It contains
  references/metadata while files use the attachment pipeline.
• If two sources disagree, pause and ask in the issue rather than choosing the
  nicer story.

Done when

• A newcomer can identify where form rendering, local persistence, push,
  server storage, and pull/export happen.
• Every source link resolves in the repository.
• The diagram renders on GitHub.
• The page clearly distinguishes observation sync from attachment sync.
• Relevant Markdown formatting checks pass.

Verify it

• Preview the Markdown and Mermaid diagram on GitHub or a compatible renderer.
• Follow every link from a clean checkout.
• Run the formatter used for repository Markdown if your editor changed the
  surrounding style.

What you will meet along the way

Almost the whole ODE ensemble, without needing to understand every instrument.
This issue is ideal for someone who learns by following data rather than reading
packages in alphabetical order.

AI tools are welcome, not required

AI can summarize files and draft a diagram, but summaries can confidently join
two code paths that never actually meet. Use it as a navigator, not a witness:
open every linked symbol, check the nearby tests, and write down anything you
could not verify. Your understanding is the valuable contribution here.