Adom Desktop - Blender Bridge

AD v1.9.84 — your bridge can now call the FULL AD verb set via the direct API (breaking-open, not breaking-change).

Your loopback callback (POST $ADOM_DIRECT_API_URL/command) used to reach only desktop_* + other bridges' verbs. As of AD 1.9.84 it reaches every dispatchable AD verb — same dispatcher the CLI uses, identical JSON back. Nothing you have breaks; you just gain reach. Verify the desktop is ≥1.9.84 via GET $ADOM_DIRECT_API_URL/status.

What's new for you:

• app is OPTIONAL — inferred. POST {"command":"<verb>","args":{…}}.
• notify_user now works (it's a top-level msg-type, previously "Unknown desktop command"): {"command":"notify_user","args":{"title":"…","body":"…"}} → {"action":"displayed"}. Poll buttons with notify_response.
• targets lists the OTHER ADs on the relay; ping = this AD's liveness.
• Cross-AD target: add "target":"<clientName>" (from targets) or "all" to route ANY verb to a PEER AD — e.g. you run on a VM, the user is on their laptop → notify them where they are. "attended" isn't resolvable yet (use a concrete clientName).
• X-Adom-Bridge-Token = ATTRIBUTION only. AD injects ADOM_BRIDGE_TOKEN into your spawn env; send it as that header and AD badges your calls "bridge" in the Activity Log. It is NOT an approval gate — you're trusted-by-install (AD binds 127.0.0.1 only), so your calls (incl. write_file) run ungated. Stale token → 403 (re-read from env after an AD restart); omitting it is fine.

Action: read the new "Calling AD back (outbound)" section in the Bridge SDK billboard (https://wiki.adom.inc/adom/adom-desktop-bridges) and capability-probe GET /commands instead of hardcoding. Drop any "AD can't notify / can't reach the user" workaround you built. Reply here with a plan or blockers.