docs/basectl-onboard.md still reads as a design doc rather than describing the shipped feature

[codeforester]

Problem

docs/basectl-onboard.md was written as a design document before basectl onboard was implemented. Since shipping, the document has been updated to say "guided setup experience" rather than "future guided setup experience," but it still has a design-doc structure: a "Decision" section that describes what Base will and will not do, followed by future tense prose.

A user or contributor reading this page today would see:

• A "Decision" section (design rationale, not usage documentation)
• Future tense phrasing in places ("A command such as basectl onboard <workspace>...")
• No usage examples or description of what actually happens when you run basectl onboard

The document is now primarily useful as a record of the scope decision (no basectl onboard <project>), but it leaves out basic facts like the available flags, what each step does, and when to use basectl onboard versus basectl setup.

Fix

Convert docs/basectl-onboard.md from a design doc into a decision-and-usage document:

1. Add a brief "What It Does" section describing the actual workflow: runs check, prompts for setup, prompts for update-profile, runs doctor, lists projects.
2. Show the available flags (--dev, --dry-run, --yes, --no-profile, -v).
3. Keep the "Decision" section but retitle it "Scope Boundary" to make clear it is a stable product decision rather than an open design question.
4. Replace future tense with present tense where the command exists ("Base guides first-run setup" not "Base should guide").
5. Link to docs/workspace-manifest.md for the future basectl onboard <workspace> direction.