[feat] Honor --json in state-changing commands (follow-up to #255)

[lugassawan]

Product framing

Impact: M · Effort: M · Tier: 2 · References: #255, #42

--json is a global persistent flag (cmd/root.go:104). #255 wired it into read commands (status/list/log), but the write commands (add, merge, remove, rename, clean, sync) still silently ignore it — returning plain text even when an automation pipeline passed --json. There is no warning when the flag is ignored, making the failure mode invisible.

---

Goal

State-changing commands (add, merge, remove, rename, clean, sync) should emit structured JSON when --json is passed, consistent with read commands wired in #255.

Motivation

Automation pipelines that pass --json globally expect all commands to honour it. When write commands silently ignore the flag and return text, parsing breaks downstream with no indication of what happened. This asymmetry was created by #255 scoping only to read commands.

Surface

• Command (cmd/*)

Specific surface: cmd/add.go, cmd/merge.go, cmd/remove.go, cmd/rename.go, cmd/clean.go, cmd/sync.go; internal/output envelope; isJSON helper at cmd/helpers.go:31

Sketch (optional)

rimba add login --json
# → {"status":"ok","task":"login","path":"/worktrees/feature/login","branch":"feature/login"}

rimba remove login --json
# → {"status":"ok","task":"login","removed":true}

Acceptance (optional)

• All six write commands check isJSON and emit a structured result via internal/output envelope when true.
• Emitting JSON does not suppress error output — errors still surface in the envelope's error field.
• At minimum a warning or error is emitted when --json was passed but a command cannot produce structured output.
• Test coverage for the JSON output path of each command.