Add Space scoping to registry pending requests

[technohippi3]

Registry configuration is instance-global: one endpoint, one token, and one
automatic-sync flag. GET /pending has no Space filter. A handle for a Space
the instance does not operate is deliberately not ACKed and is pulled forever.

For multiple operators or community-run subs instances, the registry must
therefore maintain an external token-to-Space routing table, or deploy one
registry/token queue per instance. A subs instance already knows which Spaces
its wallet can operate, so the protocol can express that scope directly.

Proposed contract

Have subs send its operable Space scope when pulling, using one of:

• GET /pending?spaces=example,another; or
• a versioned POST /pending body when the list is too large; or
• one request per Space, GET /pending?space=example.

Prefer bare canonical Space labels in the wire contract and define request
size/pagination behavior. A registry that does not support scoping should
remain usable through the current unfiltered request.

Acceptance criteria

• subs derives the requested scope from Spaces the configured wallet can
  currently operate, rather than trusting a manually typed list.
• The registry can return work only for that scope.
• Changes in delegation are reflected without restarting subs.
• The unscoped v1 registry contract remains supported.
• Empty scope and pagination behavior are documented.

This would not require subs to expose its wallet identity or private keys to
the registry.

[technohippi3]

Clarification on the proposed scope: it should be the subs instance's current
operated-Spaces set (the same local set exposed by Operator::list_spaces()),
not a fresh wallet-capability enumeration or a wallet_can_operate RPC check
for every pull. That avoids adding wallet RPC work to the registry loop and
describes which Space queues this particular instance is prepared to consume.

[buffrr]

Some of this has landed in #14 you can read REGISTRY.md for more details