feat: adopt core 0.37 — permissions as associations, and the no-bump tier

[cuibonobo]

Brings the CLI up to core 0.37 / adapter 0.36 / commons 0.31 / server 0.10.3. Two
core changes reach the command surface, so they land together rather than as two
half-updates.

Record permissions are associations

Permission[] is replaced by two association kinds — permission, whose bit is its
label and whose grantee carries a required role, and anyone, which spells
world-read affirmatively. perm calls grantAccess() / revokeAccess() instead of
reading the whole list, editing an entry and writing it back. That read-modify-write
is the thing worth dropping: between the read and the write it silently discarded
whatever a second admin granted, which is exactly the case a sharing command has to
survive.

The flags follow the model rather than the old shape:

Before	Now	Why
perm … --public	perm … --anyone	Carries read alone, so --write beside it is refused here rather than written and bounced by core
perm … --group <id> [--role admin]	perm … --group <id> --role <member|admin>	Member and admin name two different sets of people; neither is a safe default
—	perm ls <id>	The ACL was otherwise only legible in show --json
grant … --default	grant … --authenticated	A DID-holder tier, distinct from --anyone's anonymous reach — the two never share a word
grant ls [--type]	grant ls [--type] [grantee flags]	listGrants() takes a query now, widened by the listing-only --role any

perm add --read --write grants read first and perm rm withdraws write first — the
one ordering that satisfies core's rule that no write lands in a set whose grantee
cannot read it. The rule itself is left to core's message rather than re-derived
client-side. grant rm reports a count now that revoke() returns what it withdrew.

Six operations no longer bump a version

associate, dissociate, permissions, reparent, unlist and list leave
version and updatedAt where they stand. So:

• tag / link / perm / attach stop printing a version that did not move, and
  compare the record before and after instead — a repeat now says already tagged
  rather than claiming a write that did not happen.
• commit reports the version its own mutate() produced. The tag and attachment
  reconcile that follow cannot move it, so the re-read it used to do was answering a
  question nothing had changed.
• Naming contentPatch alongside parentId is what keeps a move under ifVersion.
  Pinned from both sides: a move alone does not bump, and a move-plus-patch still
  conflicts.

Also

• rm --hard reports the files the purged record referenced — destroying the record
  destroys the only rows naming them, so GC can no longer see they were referenced.
• attach add records an attachmentRecordId, so a filename resolves to the upload
  that reference came from rather than whichever record happened to upload the same
  bytes.

Breaking

The SQLite schema is create-if-missing with no migrations, so a database written
before core 0.37 keeps its old tables and fails on the first permission write.
Existing stacks must be recreated. The changeset says so, and it is minor —
the breaking slot at 0.x.

Verification

format:check, lint, test (188), typecheck, build and smoke all pass, on
this branch rebased onto current main. The smoke script now drives perm add|ls|rm --anyone through the built binary and asserts the no-bump property end to end.

Dogfooded separately against a real seeded stack in the cli-example playground —
every perm and grant path through the actual binary, tag/link/attach idempotence,
rm --hard, and a new -c → edit -c loop that moves a record to a new parent and
correctly reports an unchanged version. That turned up one thing the flags do not
show, now pinned in exercise:relations: write implies read is an invariant over
the whole set, not one grantee, so a bare write stands while an anyone read is
there — and withdrawing that read underneath it is what gets refused.

🤖 Generated with Claude Code

https://claude.ai/code/session_013wPYq2Dp59HnoYsnzYbuYP