fix(storage, workspace, cli): Report disk-full and write errors clearly

[JeanMertz]

Previously a failed conversation write from Drop (the safety net for mutation scopes that unwind before an explicit flush()) was logged to stderr and swallowed: the CLI could exit zero after silently losing data. ConversationLock and ConversationMut now record a drop-time persist failure in shared state, and the next flush(), or a take_persist_failure() drain at teardown, surfaces it so the process exits non-zero and the printer reports it. jp query, jp config set, and the jp conversation compact/edit/fork subcommands now call flush() before printing success, so a write failure is reported as an error instead of a confirmation the user cannot trust.

jp_storage::Error gains WriteFailed and OutOfSpace variants that carry the failing path alongside the OS error, replacing the bare, pathless Io variant on every write call site. A write that fails because the filesystem is full is classified separately: once seen, later write attempts on the same conversation lock are skipped rather than retried, since none can succeed until space is freed. The CLI renders OutOfSpace with a suggestion field telling the user to free disk space and re-run, and notes that anything after the last successful write was not saved.

Updates RFD 069 (guard-scoped persistence for conversations) to describe the drop-time failure reporting path and the one remaining gap: a lock-owning scope (into_mut) that drops without a later flush() or take_persist_failure() call still only logs the failure.