Stories stop carrying where they were taken, and can outlast a day

**Location.** Two story paths handed the picked file over byte for byte:

  - A story PHOTO was the one image path in the app that never went
    through `ImagePrep`, so it was uploaded with its EXIF block intact —
    including, for anything shot on the phone, the GPS coordinates. Chat
    photos have always been re-encoded and were safe by consequence
    (`Bitmap.compress` writes no EXIF); a story, which goes to every
    contact at once, was not.
  - A story VIDEO carried the capture location in the MP4 container.
    This file's own doc said "a clip that fits goes out exactly as
    picked", and that included where it was shot.

`MediaScrub` rebuilds the container with `MediaExtractor` +
`MediaMuxer`. A REMUX, not a transcode: the samples are copied across
untouched, so there is no quality loss and no codec work, and it is
cheap enough to run on every post — a scrub people wait for is a scrub
somebody eventually makes optional. Audio and video tracks only;
anything else a camera app decided to add is the kind of passenger this
exists to leave behind.

⚠️ Rotation IS carried over, deliberately. It says which way up the
phone was, not where it was, and dropping it plays every portrait story
on its side.

🔴 A scrub that fails REFUSES the post. "We could not remove the
location, so we sent it anyway" is the one outcome this must never
produce.

**Stories.** The lifetime was a constant. 1 hour / 6 hours / 24 hours /
3 days / 7 days, same set as iOS, defaulting to what it has always done.
`Conversations.postStory` already took `lifetimeSeconds` with a default,
so only the setting and the plumbing were missing — and
`Session.postStory` now REQUIRES it rather than defaulting, so a future
call site cannot silently ignore what the person chose.

⚠️ Clamped to the offered set on read: a value from a future build, or a
corrupted preference, must not post a story that expires before anybody
sees it.

Also fixes `RelayClientTest`, which had not compiled since `fetchKeys`
started returning the fnid alongside the bundles. Every other call site
in the tests was updated at the time; this one was missed, and I had not
run this suite since.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

client/src/test/kotlin/io/flamenet/client/RelayClientTest.kt

@@ -293,7 +293,11 @@ class RelayClientTest {
             .put("opk", JSONObject().put("id", oneTime.id).put("pub", Wire.b64(oneTime.publicKey)))
         server.enqueue(json("""{"devices":[$wire]}"""))
 
-        val bundles = client().fetchKeys(42)
+        // ⚠️ `fetchKeys` answers with the fnid alongside the bundles now — the
+        // address is what the key log is checked against, and returning only
+        // the bundles threw it away at the one point it is available.
+        val fetched = client().fetchKeys(42)
+        val bundles = fetched.bundles
         assertEquals(1, bundles.size)
         assertEquals(peer.deviceId, bundles[0].deviceId)
         assertEquals(oneTime.id, bundles[0].oneTimePreKeyId)