Extract generic remote chat bridge registration, queue, pending, and ack primitives

[chubes4]

Context

data-machine-chat-bridge currently provides a remote bridge protocol for external clients:

• bridge registration with callback URL
• authenticated inbound /bridge/send
• outbound response queue
• best-effort webhook delivery
• /bridge/pending polling recovery
• /bridge/ack delivery acknowledgement

Repo:

• https://github.com/Extra-Chill/data-machine-chat-bridge

This is distinct from PR #99's direct WP_Agent_Channel abstraction:

• Add WP_Agent_Channel base class for messaging transports #99

Direct channels like openclaWP wacli/WhatsApp can synchronously send replies back through the platform. Remote bridge clients like Beeper/Matrix-style daemons need a durable protocol: queue first, webhook best-effort, poll fallback, ack after accepting delivery.

Problem

These bridge semantics are not Data Machine-specific. They are generic to any external client that wants to talk to a WordPress agent runtime without being an in-process WordPress plugin.

If this stays in Data Machine, other agents-api consumers will likely reinvent it.

Proposal

Add a generic remote bridge layer to Agents API, either as PHP services first or REST routes plus services.

Potential REST shape:

POST /agents-api/v1/bridge/register
POST /agents-api/v1/bridge/send
GET  /agents-api/v1/bridge/pending
POST /agents-api/v1/bridge/ack

Potential services:

WP_Agent_Bridge_Registry::register( $client_id, $callback_url, $context );
WP_Agent_Bridge_Queue::enqueue( $agent, $client_scope, $message );
WP_Agent_Bridge_Queue::pending( $client_scope, $limit, $session_ids );
WP_Agent_Bridge_Queue::ack( $client_scope, $queue_ids );
WP_Agent_Bridge_Dispatcher::deliver( $callback_url, $message );

Generic properties:

• queue item ID
• agent ID/slug
• session ID
• role/content
• completed flag
• timestamp
• client/context metadata
• callback URL
• delivery status

Acceptance criteria

• Document the remote bridge protocol separately from direct WP_Agent_Channel transports.
• Implement or at least design generic queue/register/pending/ack primitives.
• Keep runtime-specific execution behind the canonical chat ability contract.
• Ensure delivery is queue-first; webhook delivery must not remove the item until acked.
• Ensure polling is a recovery path when webhook delivery fails.

Notes

This issue intentionally does not propose moving Data Machine-specific behavior as-is. Things like datamachine_chat_response_complete, Data Machine token internals, and bridge-mode prompt guidance should remain runtime/adaptor-specific.