Fix/magic ai extras ssrf media active content - #691

…ing headers

A PDF carrying /OpenAction /JavaScript was stored byte for byte, then linked
through Storage::url() on the public disk and rendered in an unsandboxed
iframe, so the viewer ran it on the application's own origin with no auth on
the URL.

Reject those PDFs at upload, and preview through the existing media route,
which already gates on the module permission and the path allow list. The
content type is mapped from the extension rather than sniffed, and anything
not inline-safe falls back to a download.

Chrome refuses to load its PDF viewer inside a sandboxed frame under every
token combination, so PDFs stay unsandboxed and rely on the upload check plus
the response CSP; every other inline type keeps the opaque origin.

Claude-Session: https://claude.ai/code/session_01Es54dGoiX1pP64XqxvJmXw

…tion protection

Claude-Session: https://claude.ai/code/session_01JfF9ke2aCFppkN9pYbCfKn

Resolves overlap with the MagicAI SSRF (#689) and purifier cache race (#675)
fixes that landed on 3.x independently.

Claude-Session: https://claude.ai/code/session_01JfF9ke2aCFppkN9pYbCfKn

Parallel workers boot the fixture provider against the shared database before
the framework swaps in their per-worker clone, so two workers can both pass the
existence check and race into the same CREATE TABLE. The loser now re-checks
instead of failing the run.

Claude-Session: https://claude.ai/code/session_01JfF9ke2aCFppkN9pYbCfKn

…extras keys

The active-content scan read only the first 8MB, so padding a PDF pushed the
marker out of the window. Both ends are now scanned under the same cap.

Reserved extras keys were stripped case-sensitively while validation matched
them lowercased, leaving a persisted 'URL' in the merged provider config, and a
JSON list passed validation as though it were an object.

Claude-Session: https://claude.ai/code/session_01JfF9ke2aCFppkN9pYbCfKn