create can leave a page that nothing on disk names

Start in cmd/create/create.go at reserveOne, then trace CreatePage, os.WriteFile, persistToManifest, and failKeepingPage. Compare the recovery and failure paths and confirm the chosen behavior with maintainers; done means a failed reservation cannot leave an unrecorded page, or provides an exact actionable recovery record.

create can leave a page in Confluence that nothing on disk names.

In the reserve phase, reserveOne (cmd/create/create.go) calls CreatePage and only then records the new page_id. It records it in one of two places: the file's frontmatter (os.WriteFile) or a pages: entry in markfluence.yaml (persistToManifest). If that write fails, the page already exists. Examples are a read-only .md file, a read-only markfluence.yaml, or a manifest write that gives up after its one retry.

failKeepingPage keeps the id and URL in the command's result, so the run's own output is the only record. A second create makes a second page, because nothing says the first one exists. update cannot pick it up either, because nothing names the page.

This is the one case in create's partial-failure story that update cannot recover from. The other two recover:

• A network failure during publish leaves a stub whose id is already on disk, so update finishes it.
• An unreadable attachment fails the same way, after the id is on disk.

Options:

• Check that the destination is writable before CreatePage. This is cheap, but it races: the check can pass and the write can still fail.
• Write first, create second. Reserve a placeholder on disk, create the page, then fill in the id. A failure then leaves a local marker instead of a remote orphan.
• Make the failure loud and actionable. For example, print the exact frontmatter line or manifest entry to add by hand, and give it an exit code a script can recognize.