[Nwapu-TrustJah]

Description

Resolves #235 by ensuring the VWAP pricing route respects and enforces network scoping throughout the request cycle.

Summary of Changes

• Route Threading: Updated src/routes/price.ts to extract network (req.network ?? activeNetwork), pass it to computeVWAP, and echo it in the response payload.
• SQL Query Conjunction: Confirmed src/aggregator/vwap.ts applies a strict WHERE network = $1 AND source = $2 logical conjunction to leverage the leading (network, pairKey, timestamp) index on price_points.
• TDD Test Coverage: Added Vitest tests in src/__tests__/vwapRoute.test.ts verifying cross-network isolation and default network fallback.
• OpenAPI Specs: Updated openapi.yaml and synchronized openapi.json to keep API schema validation passing.

Verification

• Ran full test suite (1,235 passing, 1 skipped).
• Verified tests/openapi.test.ts passes cleanly against regenerated openapi.json.

[Miracle656]

Merged to main as f15e3b2.

This is a better catch than the title suggests. computeTWAP already accepted a network and filtered on it (AND network = $2) — the routes simply never passed one, so the figures were computed for whatever the default happened to be rather than the network the caller asked for. That's the same class of bug #584 found in /candles, /basket and /benchmark earlier today: a price that silently mixes or mistakes chains, which looks entirely plausible in a response.

Resolving req.network ?? query.network ?? activeNetwork and then echoing the network back in the response is the right shape — a caller can see which chain answered instead of assuming.

Conflicts, all additive against work that landed today: #542 added decimal-format handling in the same query schema and handler blocks you're adding network to. I unioned them, so the schema now carries decimals, decimalFormat and network, and the handler does both.

Two things I regenerated rather than merged by hand, worth knowing for next time:

• openapi.json is generated from openapi.yaml. A hand-merged copy fails tests/openapi.test.ts's generator-match check — run npm run openapi:gen.
• clients/typescript/src/schema.d.ts — since A generated TypeScript client now ships in-repo at clients/typescript, derived from openapi.yaml and enforced in CI. Types are never hand-written: schema.d.ts is produced by openapi-typescript, and openapi-fetch provides a typed createLensClient. CI regenerates the client on every run and fails if the committed output diverges from the spec, then typechecks it. This session repaired the two files that had been corrupted, added the documented usage example and README section #403 landed today, CI runs git diff --exit-code -- clients/typescript, so any spec change needs npm run client:gen too.

I also took main's package-lock.json: this PR changes no dependency, and main's copy is the one carrying the @rolldown Linux binding that CI needs.

Lens: 116 files, 1,426 tests passing, typecheck clean.