B3 (#175): pin the AAC arm every ordinary conversion takes

audioArgs has six arms. Five are named codecs with tests; AAC arrives through the `else`,
so nothing named it -- neither "aac" nor "192k" appeared anywhere in
FFmpegCommandBuilderTest. It is the audio MP4 and M4A get, which is to say the audio the
picker offers first and most conversions produce.

Both halves are asserted, and the bitrate is the half worth arguing for: an -b:a that
quietly changed would fail nothing, look wrong in no command line, and surface only as
files that sound different from the ones the app produced last month. Both mutations
confirmed red -- 192k -> 128k and aac -> libfdk_aac.

Asserted through MP4_H264 and M4A_AAC rather than one of them, so an AAC arm added above
the `else` later has to keep answering the same way for both.

**Deliberately not added here: an ENCODABLE_AUDIO-vs-audioArgs agreement test**, the
obvious companion to VideoCodecMimeAgreementTest. It would freeze the answer to F1, which
is open: ContainerCapabilities.kt:84 says "nothing here emits a Vorbis encoder" and
FFmpegCommandBuilder.kt:188 does. docs/coverage-read-findings.md says in terms that the
tempting fix there locks in the wrong answer and that the decision comes first. This is
the AAC arm only.

563 -> 564 JVM tests, 0 failures. No production code changed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

app/src/test/java/org/libremediaconverter/ffmpeg/FFmpegCommandBuilderTest.kt

@@ -166,6 +166,30 @@ class FFmpegCommandBuilderTest {
         assertPair(cmd(OutputFormat.OPUS), "-c:a", "libopus")
     }
 
+    /**
+     * The arm most conversions actually take, and the only one in `audioArgs` with no test.
+     *
+     * `flac wav and opus select the right encoders` above covers the three named arms; MP3 has its
+     * own. AAC arrives through the `else`, so nothing named it and nothing pinned either half of
+     * what it emits -- neither `aac` nor `192k` appeared anywhere in this file. Both are shipped
+     * defaults: MP4 and M4A are the formats the picker offers first, so this is the audio
+     * every ordinary conversion gets.
+     *
+     * The bitrate is asserted as well as the encoder because it is the half a refactor is likelier
+     * to lose. An `-b:a` that quietly changed would not fail anything, would not look wrong in a
+     * command line, and would show up only as files that sound different from the ones the app
+     * produced last month.
+     */
+    @Test
+    fun `aac is the default encoder, at the bitrate the app ships`() {
+        assertPair(cmd(OutputFormat.MP4_H264), "-c:a", "aac")
+        assertPair(cmd(OutputFormat.MP4_H264), "-b:a", "192k")
+        // Through the `else` rather than through a named arm, so an AAC branch added above it later
+        // has to keep answering the same way.
+        assertPair(cmd(OutputFormat.M4A_AAC), "-c:a", "aac")
+        assertPair(cmd(OutputFormat.M4A_AAC), "-b:a", "192k")
+    }
+
     @Test
     fun `audio only formats never carry a video encoder`() {
         listOf(OutputFormat.MP3, OutputFormat.FLAC, OutputFormat.WAV, OutputFormat.OPUS)

app/src/test/java/org/libremediaconverter/work/NotificationProgressTextTest.kt

@@ -0,0 +1,89 @@
+package org.libremediaconverter.work
+
+import android.app.Notification
+import androidx.media3.common.util.UnstableApi
+import androidx.work.Data
+import org.junit.Assert.assertEquals
+import org.junit.Assert.assertNotEquals
+import org.junit.Assert.assertTrue
+import org.junit.Before
+import org.junit.Test
+import org.junit.runner.RunWith
+import org.libremediaconverter.convert.installTestWorkManager
+import org.robolectric.RobolectricTestRunner
+import org.robolectric.RuntimeEnvironment
+import java.util.UUID
+
+/**
+ * The two things a progress notification can say, and that they are not the same thing.
+ *
+ * An assertion gap rather than a coverage one, and the distinction is the reason this file exists.
+ * JaCoCo is green on `build`'s `if (indeterminate)`, because `ProgressNotificationTest` drives it
+ * through a real worker -- but that test reads only the notification id and
+ * `Notification.EXTRA_PROGRESS`. **Nothing had ever read the text.** Swapping the two branches, or
+ * collapsing them into one string, passed the entire suite.
+ *
+ * What it costs to get wrong is small and constant: a conversion that has been running for four
+ * minutes still saying "Preparing", or one that has not started reporting yet claiming 0%. Neither
+ * is a crash, and neither would be found by anything else here -- which is exactly the kind of
+ * thing that survives for a long time.
+ *
+ * Nothing else in the suite constructs [ConversionNotifications] directly.
+ */
+@UnstableApi
+@RunWith(RobolectricTestRunner::class)
+class NotificationProgressTextTest {
+
+    /**
+     * `build` reaches `WorkManager.getInstance` for the Cancel action's PendingIntent, so the
+     * notification cannot be built at all without one. That coupling is why nothing had ever
+     * constructed this class directly and read what it produced.
+     */
+    @Before
+    fun setUp() {
+        installTestWorkManager(RuntimeEnvironment.getApplication(), Data.EMPTY)
+    }
+
+    @Test
+    fun `an indeterminate notification says something different from a measured one`() {
+        val context = RuntimeEnvironment.getApplication()
+        val notifications = ConversionNotifications(context)
+
+        val preparing = notifications.build(JOB_ID, TITLE, percent = 0, indeterminate = true).text()
+        val measured = notifications.build(JOB_ID, TITLE, percent = 42, indeterminate = false).text()
+
+        assertNotEquals(
+            "the two states have to read differently, or the text says nothing at all",
+            preparing,
+            measured,
+        )
+        assertTrue(
+            "a measured notification has to carry its percentage, got \"$measured\"",
+            measured.contains("42"),
+        )
+        assertTrue(
+            "an indeterminate one must not invent one, got \"$preparing\"",
+            !preparing.contains("42") && !preparing.contains("0"),
+        )
+    }
+
+    /**
+     * The title is the caller's, not the builder's -- it is the file the user picked, and it is what
+     * tells two simultaneous conversions apart in the shade.
+     */
+    @Test
+    fun `the notification is titled with the file it is converting`() {
+        val context = RuntimeEnvironment.getApplication()
+
+        val built = ConversionNotifications(context).build(JOB_ID, TITLE, percent = 10)
+
+        assertEquals(TITLE, built.extras.getString(Notification.EXTRA_TITLE))
+    }
+
+    private fun Notification.text(): String = extras.getString(Notification.EXTRA_TEXT).orEmpty()
+
+    private companion object {
+        const val TITLE = "holiday.mp4"
+        val JOB_ID: UUID = UUID.fromString("00000000-0000-4000-8000-00000000000a")
+    }
+}