Turn an internal spec into user-facing docs

The feature shipped and the only writing about it is the design doc.

Rewrite the internal spec below as documentation for the people who will use the feature.

First, state in one line who that reader is and what they are trying to accomplish. Everything else follows from that.

Then:
- Reorganise around user tasks, not around the system's components or the order it was built in
- Cut everything that is implementation detail the user cannot observe or act on
- Cut the rationale, the rejected alternatives, and the rollout plan. Keep rationale only where it prevents the reader misusing the feature
- Convert every internal name to whatever the user actually sees in the interface, and list any that have no user-facing name so we can fix that
- Turn each requirement into either an instruction or a reference entry

End with a list of open questions the spec leaves unanswered that a real user will ask on day one.

Spec:

Editing and auditing docs. Finding what is stale or undocumented, cutting what the code already says, rewriting for the reader.