v0.33.0 — recipes by name, a doctor that means it, and the tools the docs promised

Four defects were live in the published 0.32.1. This removes them.

• /baron:task-move failed for every user. The recipe shipped and the skill called it, but it was never registered as a built-in, so it returned RECIPE_NOT_FOUND — while the AGENTS.md steering baron init writes told the agent to prefer it. (#93)
• baron init wrote tool names the server does not publish into the user's own AGENTS.md, where they survive every upgrade and an agent obeying them asks for tools that are not there. (#94)
• The quick start's third step was a dead end. The CLI could not resolve a recipe by name, so --recipe <path-to>/task-start.yaml had no path to give. baron run --recipe task-start now works, through the same resolver the MCP server uses. (#95)
• baron doctor reported OK and exited 0 on a credential it had not verified — a probe that threw was recorded as merely unchecked. A probe that breaks now fails the report; a provider that simply has no probe still passes. (#99)

New

• baron run --recipe <name> resolves built-ins and project recipes by name, identically to MCP.
• The GitHub device flow opens the approval page for you. The URL and code are still printed first and never replaced — every reason opening fails is a reason you still need to read them.

Also

Documentation was swept against the code rather than re-read: fifteen dead tool names across a dozen files, a roadmap still advertising 36 tools, an op table missing eight ops that the shipped recipes use, blocked still taught as a workflow role after it became a flag, and a licence NOTICE naming ten packages that were never published. Five tests now tie those documents to the code they describe, so the next drift is a red build rather than a discovery.

Full log: v0.32.1...v0.33.0