feat(org-relations, org-tags): org↔org edges + org tags land as six capabilities

Organizations can finally know about each other: parent/child/peer
relations with a typed kind and free-text description, plus the first
org-level tag mechanism (has_tag observations + the existing tag_vocab).
Everything reachable over the wire — no direct DB writes needed.

New module services/record-surrealdb-resolver/src/org-relations.ts serves
organization.relate / relations / unrelate / relation.update and
organization.tag.add / tag.remove. Org→org edges ride the SAME affiliations
RELATE table as person→org edges with an explicit edge_type='org_org'
discriminator; canonical direction in=child/out=parent, stored rel
'child_of'|'peer', parent/child/peer projected at read time relative to the
focused org. One relation per pair (both-direction dedup, client_access
union on re-relate). related_to / relation_removed observations for the
audit trail.

resolver.ts: organization.detail now returns tags: string[] (per-client
has_tag observations — never fields on the shared multi-tenant org row).

domains.ts: ensureTagInVocab exported for reuse; tags keep the house
toDashed behavior (dashes-not-spaces, operator owns casing).

capabilities.ts: six verb→subject entries + 30s timeouts.

Verified: tsc clean on both services; resolver boots with the new
registrations; live NATS checks — relations trichotomy read, self-relate
guard localized ok:false, detail.org.tags present.

Refs #49 #50 (one module, one commit — tags and relations share the slab).

Files changed:
- services/record-surrealdb-resolver/src/org-relations.ts (new)
- services/record-surrealdb-resolver/src/resolver.ts
- services/record-surrealdb-resolver/src/domains.ts
- services/record-surrealdb-resolver/src/server.ts
- services/workspace/src/capabilities.ts
- changelog/2026-07-27_01_Organizations-Learn-Their-Family-Tree-Parent-Child-Peer-Relations-Plus-Org-Tags.md

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RW28dw3kQAKXr2ZNefCukE

Author: mpstaton

changelog/2026-07-27_01_Organizations-Learn-Their-Family-Tree-Parent-Child-Peer-Relations-Plus-Org-Tags.md

@@ -46,3 +46,50 @@ and the issue that demanded it,
 ## What landed
 
 <!-- one beat per closed ticket — step, code sample of the interesting part, gotchas -->
+
+### The capability slab: six new verbs, one new module (#49, #50)
+
+`services/record-surrealdb-resolver/src/org-relations.ts` is the whole
+backend: `organization.relate / relations / unrelate / relation.update`
+plus `organization.tag.add / tag.remove`, registered domains.ts-style and
+mapped through the workspace verb table. Org→org edges live in the same
+`affiliations` RELATE table as person→org edges, discriminated explicitly:
+
+```sql
+RELATE $child->affiliations->$parent SET
+    edge_type = 'org_org', rel = $rel, kind = $kind, description = $description,
+    client_access = [$client], added_at = time::now();
+```
+
+The parent/child/peer trichotomy the operator speaks is a read-time
+projection — canonical direction is always `in` = child, `out` = parent,
+and `projectRel()` names the edge from whichever org you're looking at:
+
+```ts
+function projectRel(edge: PairEdge, focused: unknown): OrgRelKind {
+  if (edge.rel === 'peer') return 'peer';
+  return String(edge.in) === String(focused) ? 'parent' : 'child';
+}
+```
+
+One relation per org pair (dedup scans both directions; an existing edge
+unions `client_access` and reports `created: false`, the `person.affiliate`
+precedent — not an error). A parent↔child flip in `relation.update`
+re-normalizes by delete + re-relate, because RELATE edges can't swap
+`in`/`out` in place.
+
+Org tags are `has_tag` observations (subject = org RecordId, per-client),
+never fields on the shared org row — the same multi-tenant rationale that
+put `relevance` on the affiliation edge. `organization.detail` now returns
+`tags: string[]`. Two gotchas worth recording: `tag.suggest`/`tag.apply`
+already existed (so no new vocab verb — the datalist rides `tag.suggest`,
+and the handlers reuse `ensureTagInVocab`, newly exported), and the house
+tag normalizer `toDashed` deliberately **preserves operator casing**
+("Impact of AI" → "Impact-of-AI"), so Train-Case lives in the vocabulary
+convention, not a forced normalizer.
+
+Verified: both services typecheck clean, resolver boots with the new
+registrations, and three live NATS checks pass (empty trichotomy read on
+`the-aspen-institute`, self-relation guard → localized `ok:false`,
+`detail.org.tags` present). Full write-path proof is the proof script's
+job (#51).

services/record-surrealdb-resolver/src/domains.ts

@@ -116,7 +116,7 @@ async function applyBibToRegistry(
   if (set.length) await db.query(`UPDATE sources SET ${set.join(', ')} WHERE source_uuid = $u;`, vars);
 }
 
-async function ensureTagInVocab(db: Surreal, client_slug: string, tag: string): Promise<void> {
+export async function ensureTagInVocab(db: Surreal, client_slug: string, tag: string): Promise<void> {
   if (!tag) return;
   const seen = first<{ tag: string }>(
     await db.query('SELECT tag FROM tag_vocab WHERE client_slug = $c AND tag = $tag LIMIT 1', { c: client_slug, tag }),