v1.1.0 — Social Inbox support

The inbox endpoints are now part of the ContentStudio public API, so the
CLI and the agent skill cover them: 30 new commands under `inbox:*` for
DMs, post comments, reviews, contacts, and tags.

Built from the published OpenAPI spec, then verified end-to-end against a
live workspace. Where the two disagreed, the live behaviour won — the
notes below record the differences, because several of them are silent
failures rather than errors.

- Reads: `inbox:list` (unified search over conversations/posts/reviews),
  `inbox:summary`, `inbox:messages`, `inbox:comments`, `inbox:notes`,
  `inbox:bookmarks`, `inbox:contact`, `inbox:tags`.
- Writes: `inbox:send`, `inbox:comment-add` (comment, threaded reply, or
  Facebook private reply), `inbox:review-reply`, `inbox:note-add`.
- Triage/moderation: `inbox:mark-read`, `inbox:update`, `inbox:star` /
  `inbox:unstar`, `inbox:comment-hide`/`-unhide`, `inbox:comment-like`/
  `-unlike`, `inbox:comment-delete`, `inbox:message-delete`,
  `inbox:review-reply-delete`, `inbox:contact-update`.
- Tags: `inbox:tag-create`, `-update`, `-delete`, `-merge`, `-attach`,
  `-detach`.

Identifier mapping (the biggest trap): pass `element_details.element_id`,
not the top-level `element_ref`. Despite the request field being named
`element_refs`, the bulk-update and tag endpoints reject an `element_ref`
with a 404 INBOX_UPSTREAM_ERROR, and `inbox:messages` / `inbox:comments`
return an empty list for it. Both docs now lead with this.

Response handling: the inbox service does not use the `{status, message,
data}` envelope the rest of the v1 API uses. Each endpoint returns its
collection under its own key (`elements`, `messages`, `comments`, `tags`,
`contact`, `element_counts`) with per-endpoint paginator names. The
wrappers normalise all of it, so `--json` keeps the usual
`{ok, data, pagination}` shape. Post comments page on `total_threads`,
not `total_comment_count`. `inbox:notes` and `inbox:bookmarks` paginate
even though the spec documents neither a schema nor pagination.

Safety: inbox writes are customer-facing with no undo, so SKILL.md
requires a `--dry-run` preview and explicit approval before sending. New
`ConflictError` (409) carries a do-not-blindly-retry hint, because the
API reports a send's outcome as undetermined rather than failed.
`inbox:update` surfaces 207 partial success via `missing_ids`, and
`inbox:contact-update` warns that a contact update applies to every
element for that contact, not just the one addressed.

- API limits enforced client-side: `--limit` <= 200, <= 100 refs per
  bulk update, tag name <= 50 chars, exactly one operation per
  `inbox:update`.
- `inbox:messages` interleaves activity events (`message: null` with an
  `action` block) among real messages; they are rendered as event rows
  and documented so agents do not count or quote them as customer text.
- Client gained `patch()` — three inbox endpoints use PATCH and the
  client had no PATCH support. `emitDryRun`/`parseJsonOption` moved to
  `cliCtx.ts` so `crud.ts` and `inbox.ts` share one copy.
- Fixed pre-existing e2e breakage: `listAccounts`/`listWorkspaces` return
  `{data, pagination}` but the suite treated them as arrays, so it failed
  with a misleading "no connected accounts". Added inbox e2e coverage and
  made the CLI suite hermetic against ambient CONTENTSTUDIO_* vars.
- Version 1.1.0 across SKILL.md, package.json, plugin.json and
  marketplace.json; the last two had drifted at 1.0.0. Removed SKILL.md's
  trailing `## Version` section, which had drifted to 1.0.0 — the
  frontmatter is now the single source.

- Rebased onto #2 (posts:update, approval workflows). Since this bump sets
  the package to 1.1.0, the CHANGELOG's "Unreleased" section from that PR
  is folded into the 1.1.0 entry as its own subsection, bullets verbatim —
  those changes ship in this version too. SKILL.md's mutating-command list
  is the union of both sets.