Add REST endpoints for signed price feeds (API Publisher)

[grantfox-oss]

📝 Description

Context: The API app (apps/api/) currently only exposes a root message and GET /health. The pipeline will serve signed price data to clients; this issue adds the price endpoints that expose signed feeds produced by the aggregator + signer.

Goal: Implement REST endpoints to read signed price data, e.g. GET /prices/:symbol (or GET /prices/latest/:symbol) and GET /prices/latest (all symbols). Data can be in-memory for now (e.g. a simple store or service that the aggregator/signer populate via internal API or stub). Focus on route shape, response format, and integration with @oracle-stocks/signer types (SignedPriceProof). No full end-to-end ingest yet — minimal scaffolding to get the API contract right.

Expected inputs/outputs:

• Input: HTTP GET with optional symbol.
• Output: JSON with signed price proof(s), e.g. SignedPriceProof or { symbol, price, timestamp, signature, publicKey }. Use 404 when symbol is unknown and 503 if price data is not available yet.

Tech stack / conventions: NestJS (existing in apps/api), TypeScript. Reuse or depend on @oracle-stocks/signer for types; optionally @oracle-stocks/shared for shared types. Keep controllers thin; put logic in a dedicated prices service.

Complexity: ~6/10 — well-scoped REST layer and one or two endpoints; in-memory or stub data source is enough for this issue.

---

✅ Requirements

• Add a Prices module (or extend AppModule) with a controller and service.
• Implement at least:
  • GET /prices/latest — return latest signed price for all configured symbols (array of signed proofs).
  • GET /prices/latest/:symbol (or GET /prices/:symbol) — return latest signed price for one symbol (single signed proof).
• Response body shape matches or is compatible with SignedPriceProof from packages/signer.
• Return 404 when the requested symbol has no data; 503 when the price source is not ready (e.g. no data at all).
• Use a simple in-memory store or stub that can be replaced later by real aggregator/signer integration; document how the store is intended to be filled (e.g. internal call or background job).
• Keep existing GET / and GET /health unchanged.

---

🎯 Acceptance Criteria

• GET /prices/latest and GET /prices/latest/:symbol (or equivalent) are implemented and documented (e.g. in README or OpenAPI comment).
• Responses return JSON with signature and publicKey (signed proof shape); 404/503 behavior is as specified.
• At least one unit or integration test for the new endpoints (e.g. controller or e2e).
• apps/api builds and passes npm run build and tests.
• No breaking changes to existing health or root endpoint.

---

📁 Expected files to change/structure

• apps/api/src/prices/ — e.g. prices.module.ts, prices.controller.ts, prices.service.ts.
• apps/api/src/app.module.ts — import and register the prices module.
• apps/api/src/main.ts — only if global prefix or versioning is added (optional).
• New or updated spec: prices.controller.spec.ts or prices.service.spec.ts (or e2e).
• apps/api/README.md — document new routes and response format (optional but recommended).

---

Note: don't worry about CI workflow for now, it's an issue on our end we will fix after we merge all issues!

Thank you for taking this issue! You are helping us make RWAs consumer friendly on Stellar.

[JosueBrenes]

I would solve this issue by creating a dedicated prices module in NestJS with a PricesController and PricesService, keeping the controller thin and placing all business logic inside the service. I would implement GET /prices/latest and GET /prices/latest/:symbol, reusing the SignedPriceProof type from @oracle-stocks/signer to ensure the response contract matches the signer package. An in-memory Map<string, SignedPriceProof> would act as a temporary store, preloaded with stub data to simulate signed prices without requiring full aggregator integration.

The service would return 503 when no price data is available at all (source not ready) and 404 when a specific symbol is requested but not found. I would also add at least one unit or e2e test covering success and error cases, ensure the app builds and existing / and /health routes remain unchanged, and briefly document the new endpoints and response shape in the API README for clarity.