Use dynamic test origins instead of hardcoded list

## Summary
Hardware origin dropdown still uses a hardcoded `TEST_ORIGINS` list. New origins only appear after a code change (#1983).

## Goal
Load `test_origins` from the `tests` table (distinct origins in the requested interval), with caching.

## Why not `hardware_status`
That table only includes tests with a platform. The dropdown would miss test origins that never appear on a platform. We need origins from `tests` itself.

## Dependency
A direct distinct over current `tests` is too slow (previously ~minutes / timeouts). This should wait on the analysis-oriented schema work in #1947 (e.g. leaner run facts), which should make this query practical.

## Acceptance criteria
- [ ] `/origins` serves `test_origins` from `tests` data, not a static list
- [ ] New origins appear without a code change (within cache TTL)
- [ ] Hardware listing still filters correctly by test origin
- [ ] Endpoint stays fast under normal load

## Related
- #1983
- #1947

Start at the /origins endpoint and inspect how the hardware listing applies test-origin filters. Review the tests table and the analysis-oriented schema work in #1947 before choosing the query path. Done means origins come from distinct tests data, new origins appear within the cache TTL, hardware filtering remains correct, and the endpoint stays fast under normal load.

Written by the indexing model from the issue text.