[OoP-3] DirectoryService REST-Endpoint Discovery

[mattgarmon]

Parent: OoP

Description

Extend DirectoryService so gears can register and resolve each other's REST endpoints and OpenAPI specs. DirectoryService itself remains a gRPC API (DirectoryClient / DirectoryGrpcClient); the new resolve_rest_service / get_openapi_spec operations are gRPC RPCs that carry REST-endpoint metadata. The flow is: a gear queries the directory over gRPC, then talks to the resolved gear over REST.

PRD: cpt-cf-fr-oop-lifecycle, cpt-cf-fr-direct-communication
Design: cpt-cf-component-directory-rest
Effort: Medium

Overlap with PR #4084. PR #4084 already extends the directory with REST endpoint discovery (resolve_rest_service, plus directory.proto and gear-orchestrator/src/server.rs changes). If it lands, OoP-3 narrows to the rest_endpoint / openapi_spec registration fields, get_openapi_spec, and any orchestrator-side storage not already covered — reconcile against #4084 before starting.

Tasks

• 3.1 Extend RegisterInstanceInfo in libs/system-sdks/sdks/directory/src/api.rs:
  • rest_endpoint: Option<ServiceEndpoint> — gear's HTTP base URL
  • openapi_spec: Option<String> — gear's OpenAPI JSON
• 3.2 Add resolve_rest_service(gear_name: &str) -> Result<ServiceEndpoint> to DirectoryClient trait
• 3.3 Add get_openapi_spec(gear_name: &str) -> Result<String> to DirectoryClient trait
• 3.4 Update the directory.proto definitions for the new RPCs (DirectoryService is gRPC — these are gRPC RPCs returning REST-endpoint metadata)
• 3.5 Implement server side in gear-orchestrator — store REST endpoints and OpenAPI specs, serve resolution queries
• 3.6 Implement in DirectoryGrpcClient
• 3.7 Unit + integration tests: register with REST endpoint, resolve it, retrieve OpenAPI spec

Acceptance Criteria

• A gear can register its REST endpoint + OpenAPI spec and another gear can resolve both via DirectoryClient