v0.11.0

Graceful overload handling

When demand exceeds what the portal can serve, it now sheds load deliberately instead of degrading — clients get an immediate, explicit overload response rather than slow queries and workers wrongly banned as too slow.

• Backpressure instead of collapse. A request that can't be served reliably is rejected up front, and response downloads are globally scheduled and prioritized so heavy traffic no longer starves the queries already in flight. (#91)
• A distinct status code for overload. An overloaded portal answers 529 rather than 503, separating "too many requests are hitting this portal" from a general service failure. (#91)
• Faster data-heavy streams. When a worker response is cut short by the size limit, the portal now schedules the rest of the chunk immediately instead of waiting for the partial result to reach the client. Large single-chunk queries no longer run sequentially. (#102)
• An OpenAPI description of the HTTP API. (#112)
• Unknown config fields no longer stop startup. They are reported as a warning, so a config written for a different portal version still boots.
• request_id is back in JSON logs. Span fields were missing from the JSON format and are included again.

Full Changelog: v0.10.1...v0.11.0