Background memory: keep or release the editor ExoPlayer on ON_STOP — decide from measurement

[stozo04]

Spun out of #148 (Play technical quality requirements) — the background-memory question the audit deliberately left open.

Current state

MainActivity.onTrimMemory acts only on the legacy foreground pressure levels; TRIM_MEMORY_UI_HIDDEN / TRIM_MEMORY_BACKGROUND release nothing. That is deliberate — ui/MemoryPressure.kt documents why the lifecycle levels must not degrade the editor (PR #58 review) — and stays that way.

What the app keeps alive while backgrounded:

• The Trim filmstrip bitmaps — the only bitmaps worth releasing on UI_HIDDEN. Removed at the source by the sub-issue that decodes them at tile size, so there is nothing to release here once that lands.
• The editor's ExoPlayer — BoomerangEditorScreen pauses it on ON_STOP and resumes on ON_START; it is released only on leave-composition. Decoder buffers, the surface, and any active effects pipeline stay resident in the background.

Decision rule

Do not change the player lifecycle on speculation. #148 item 2 measures anonymous RSS + swap in Play's four process states on the API-37 emulator (Pixel_8 AVD), including background = backgrounded from the editor with a look applied. Then:

• Background number comfortably under Play's 1 GB (4 GB tier) threshold and not within 2× → close this as "measured, no change".
• Otherwise → release the player on ON_STOP and rebuild on ON_START (the editor already rebuilds the player via the epoch bump for the effects-teardown path — reuse that, no new mechanism), re-measure, and re-check the reverse-preview codec-slot contention that motivated pause-not-release in the first place.

Blocked on #148 item 2 (the measurement) and the filmstrip sub-issue.