initial implementation of options filtering for byoc jobs

[mikezupper]

What does this pull request do? Explain your changes. (required)

Why You'd Want Options Filtering as a BYOC Runner Developer

The Problem Without It

Imagine you have two workers registered for the text-to-image capability:

• Worker A: RTX 3080 (10GB VRAM), running Stable Diffusion 1.5
• Worker B: A100 (80GB VRAM), running FLUX.1

Without filtering, a job requesting FLUX.1 could land on Worker A, which can't run it. The orchestrator has no way to say "this job needs Worker B specifically."

---

Layer by Layer

1. Worker Registration (ExternalCapability.WorkerOptions)

When your runner registers itself with the orchestrator, it now includes metadata about what it actually supports:
{"model": "flux-1", "vram": "80", "precision": "fp16"}
This is your runner advertising its capabilities beyond just "I handle text-to-image."

2. Orchestrator Capacity (GetFilteredCapacity)

When the gateway asks "how much capacity do you have for text-to-image?", the orchestrator can now answer specifically for the requested model. If the gateway asks "how much FLUX.1 capacity do you have?", it won't count
your SD1.5 workers. The gateway stops wasting time talking to orchestrators that can't actually handle the job.

3. Job Token (JobToken.WorkerOptions)

When the orchestrator hands back a token to the gateway, it includes the worker options it found. This lets the gateway do a second sanity check — "does this orchestrator actually have what I need?" — before committing
to routing the job there.

4. Runner Selection (SelectAndReserveRunner)

Previously, when a job arrived, the orchestrator just grabbed any available runner for that capability. Now it finds the best matching runner for the specific model/hardware requested, and atomically reserves it so no
other job steals it in the meantime.

5. Job Parameters (JobParameters.OptionsFilter)

The job client (whoever is submitting work) can specify what they need in the job request:
{"options_filter": {"model": "flux-1"}}
This filter flows all the way from the client → gateway → orchestrator → runner selection.

6. Network Capabilities (CapabilityOptions in /getNetworkCapabilities)

The gateway's discovery endpoint now publishes what options each orchestrator's workers support. Clients can query this first to know what's available before submitting a job — like a menu of supported models.

7. /process/options endpoint (model discovery)

Both the orchestrator and gateway expose this endpoint. The gateway fans out to all its orchestrators and aggregates the results. This is what a UI or API client would call to populate a "choose your model" dropdown.

---

The Real-World Payoff

As a BYOC runner developer, this means:

• You can register specialized workers (e.g. a node with a specific GPU/model) and guarantee jobs that need that specialization actually reach you
• You don't get flooded with jobs your hardware can't handle, wasting capacity and returning errors
• Multiple runners for the same capability can coexist on the same orchestrator, each advertising different specs — the orchestrator routes intelligently between them
• Clients get predictable job routing instead of lottery-style assignment

This specification details a mechanism for dynamic, capability-based routing in the Bring Your Own Compute (BYOC) network. By decoupling domain-specific worker capabilities from the core Orchestrator and Gateway routing logic, BYOC workers can self-report their configuration (options), and clients can define strict requirements (filters). The Gateway evaluates these filters using a lightweight matching engine to determine Orchestrator eligibility.

Specific updates (required)

How did you test each of these updates (required)

Does this pull request close any open issues?

Checklist:

• Read the contribution guide
• make runs successfully
• All tests in ./test.sh pass
• README and other documentation updated
• Pending changelog updated