Keep the local API responsive during cryptographic operations

[brainx]

Cryptographic operations currently run synchronously inside async request handlers, blocking the local API during key generation, password derivation, encryption, and decryption. This change moves that work to a dedicated worker so health checks, static assets, and key inspection can continue while an operation runs.

• Admit one generate/encrypt/decrypt request per server process after authorization and Content-Length validation, before parsing uploads. Concurrent requests receive 429 server_busy with Retry-After: 1 instead of accumulating memory-heavy work.
• Keep admission until both the request/response lifecycle and the underlying worker finish. Cancelling a request cannot free the slot while native work continues; application shutdown waits for running work.
• Run health work separately, retain existing cryptographic formats and successful API responses, and document manual retries. Regression tests verify that the web client displays busy guidance and never automatically resubmits sensitive requests.
• Include the worker in the distribution and CI checks.

Validation on macOS with Python 3.13:

• Python suite without native liboqs: 413 passed, 15 skipped, 88.45% combined coverage; the worker has 100% coverage.
• Native cryptographic suite: 146 passed.
• npm run check and npm run build: passed, including 4 API client tests and 83 UI tests.
• Black, flake8, mypy, and Bandit checks for changed Python code: passed.
• Built and installed the wheel, verified isolated imports and bundled UI, then completed real HTTP key generation and an encryption/decryption round trip against the installed application. The verification server was stopped.
• Deterministic concurrency tests cover response delivery, cancellation, queued-future cancellation, early upload rejection, authorization/body-limit precedence, failure recovery, and shutdown.

Validation limits: native checks used the existing liboqs 0.15.0 installation with the 0.16.0 Python wrapper and emitted a version warning. Linux and Windows runtime checks were not run locally.

This PR targets main independently of the file-workflow fixes in #58.

The development lock and CI compiler now use pip 26.2.1 with compatible pip-tools 7.6.1, addressing GHSA-qwm4-qh6w-59xr. Matching minimum versions prevent reinstating the vulnerable installer; checker expectations and setup instructions are synchronized. The local native install directory is ignored without deleting its files.

Dependency validation: hash-locked installation and pip check passed; the development-lock audit and npm audit reported no known vulnerabilities; 32 dependency-lock tests, Black, flake8, mypy, and Bandit passed. The two updated lock entries were generated with pip-compile on macOS and copied into the existing lock, preserving unchanged Linux-only entries because a local Linux runtime was unavailable. The complete canonical lock regeneration check passed in Ubuntu CI on the updated branch.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-05T10:00:32.025942Z	598529d	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.