docs: lead with the plan at a glance

The direction document opens with reasoning, which is right for settling a
decision and wrong for reading it back later. Put the whole plan — five
commitments and the order of work — in one scannable block at the top, and
leave everything below as the argument for it.

Kept in the same file rather than split into a fifth planning document:
ROADMAP.md, PLAN.md and ARCHITECTURE.md already overlap, and two of them
are stale.

docs/STORAGE-AND-SYNC.md

@@ -8,6 +8,35 @@
 > `ROADMAP.md` / `PLAN.md` remain known-stale and are due a deliberate pass;
 > this document does not attempt it.
 
+## The plan, in short
+
+**What we're building**
+
+1. **Our own provider.** Vendor the Apache-2.0 dmfs task provider in-tree as
+   `:provider`, renamed to our own authority and permission namespace. Our
+   database, our namespace — coexists with everything, replaces nothing.
+2. **Our own sync.** An Agendula sync adapter, so remote storage never depends
+   on another app's roadmap.
+3. **The user picks the mode.** Local-only · Synced · External provider.
+4. **Least permission.** Ask only for what the chosen mode needs, when it needs
+   it.
+5. **Kit-first.** Anything that isn't task-domain goes to floret-kit.
+
+**In what order**
+
+| # | Step | Why now |
+|---|---|---|
+| 1 | Merge `fix/provider-interaction-review` | unmerged and rotting; touches the same permission flow as step 2 |
+| 2 | Vendor `:provider` under our own authority | the identity, done once — and it ships a complete local-first app |
+| 3 | Export / backup | our data now lives only in our app's private storage |
+| 4 | File the DAVx5 issue | cheap, non-blocking, serves F-Droid users |
+| 5 | Sync adapter | the 1.x arc; design discussion pending |
+
+Everything below is the reasoning behind those choices, the alternatives that
+were rejected, and the constraints they have to survive.
+
+---
+
 ## The decision
 
 Agendula gets its **own identity all the way down** — its own task database