AI Agent Run Media still stores a second inline copy of generated media (InlineData) after #4192

Follow-up from the review of #4192 (filed at the reviewer's request).

## What
`AgentRunner.SaveAgentRunMedia` runs just before `CreateMediaArtifacts` on every run and writes `mediaEntity.InlineData = mediaOutput.data` — the full base64 of each generated image / audio / video — into `MJ: AI Agent Run Media` (`AgentRunner.ts` ~line 1161). #4192 moves the *artifact* copy to the configured file storage, but this audit-table copy stays inline, so each generated image is still stored once as base64.

## Impact
The 129 MB / ~5 MB-per-day figure in #4192 measured `ArtifactVersion.Content` only; the same bytes sit in `AIAgentRunMedia.InlineData`. #4192 roughly halves the growth rather than eliminating it.

## Design question
Should the audit row reference the `MJ: Files` record (the blob #4192 now uploads) instead of carrying the bytes — e.g. a nullable `FileID` on `AIAgentRunMedia`, with `InlineData` used only when no storage account is configured (the same fallback contract `uploadToStorageIfConfigured` already implements)? That is a schema change (migration + CodeGen) and a decision about what the audit table is for, so it is out of scope for #4192.

## Also worth deciding
Whether existing inline rows should be migrated (`mj artifacts reclassify` may cover the artifact side; nothing covers the audit table).

Start in AgentRunner.ts around SaveAgentRunMedia (~line 1161), then read CreateMediaArtifacts and the uploadToStorageIfConfigured fallback contract from #4192. Decide whether AIAgentRunMedia should reference MJ: Files through a nullable FileID, define handling for existing InlineData rows, and document the required migration and CodeGen changes.

Written by the indexing model from the issue text.