fix(release): correct @refarm.dev/dispatch-surface consumer-pull wording (channel-dispatch, not product commands)

The first vault-seed dogfood surfaced real consumer feedback: dispatch-surface's proofTarget
said "dgk exposes product commands through dispatch-surface-compatible descriptors", which
reads as a CLI command registry — and nearly led the consumer to model its CLI dispatch on
it. The real API is channel/transport dispatch (parseTaskTransport for file/http/channel:*,
the control-surface adapter, channel effort payloads for the runtime HTTP surface). Corrected
downstreamUse + proofTarget so SDK consumers adopt it for what it is, not what it isn't.
Descriptive metadata only — handoff Status stays ok, boundary audit unaffected.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011ZL1AroezCKPRB7aNGoygc

Author: Arthur Silva

refarm.config.json

@@ -849,8 +849,8 @@
 				],
 				"consumerPull": {
 					"proofId": "dispatch-surface.dgk-descriptor",
-					"downstreamUse": "Multi-surface command/action descriptor substrate",
-					"proofTarget": "dgk exposes product commands through dispatch-surface-compatible descriptors",
+					"downstreamUse": "Channel/transport dispatch primitives — parseTaskTransport (file/http/channel:*), the control-surface adapter, and channel effort payloads that feed the runtime HTTP surface.",
+					"proofTarget": "Consumers route channel/transport dispatch operations through these shared primitives. This is NOT a product-command/CLI registry — product commands stay in the consumer command layer (the old wording wrongly suggested modeling CLI commands on it).",
 					"ownershipBoundary": "Surface labels, routes, and product-specific actions remain downstream"
 				}
 			},