iOS trimAudio: AAC path and bit-depth handling produce wrong output #451

Two defects in trimAudio that predate #450 and are outside its scope (bridged numeric narrowing). Both verified against main.

AAC path writes source-format buffers to a target-rate writer

AudioProcessor.swift (main:912) writes the input buffer straight to a writer configured at the target rate:

try outputFile.write(from: buffer)   // buffer is in inputFormat, writer is at targetSampleRate

That violates AVAudioFile's format-match contract. A one-second 44.1 kHz source written at 22.05 kHz comes back as roughly two seconds.

The WAV path was fixed in #450 — it converts, sizes the output buffer by the rate ratio, and converts against the writer's resolved format rather than the requested one, because a WAV writer silently clamps 384 kHz to 192 kHz. The AAC path needs the same treatment.

The AAC writer is also still alive when createTrimResult reopens the file, which reports length == 0 (probed: 0 before writer teardown, 44100 after). #450 scoped the two WAV writers for exactly this; this third one was missed.

Bit depth

• An omitted bitDepth defaults to 16 during a rate or channel conversion, though the public contract says input format is preserved.
• A bit-depth-only request takes the WAV fast path and is ignored entirely — fix(audio-studio/ios): clamp bridged durations where they become sample counts #450 added outputDiffersFromInput to the fast-path gate but deliberately left bitDepth out, because that path writes with inputFormat.settings.
• createTrimResult now derives sample rate, channels and duration from the reopened file, but still trusts the passed bit depth.

Suggested: resolve depth from audioFile.fileFormat, include it in the fast-path gate, and derive the reported depth from the written file. Verify 16→32, 32→16, and omitted-depth against the reopened WAV.

Why not fixed in #450

That PR is a numeric-narrowing fix that has already grown to ~880 lines. Each round of review surfaced another pre-existing resampling defect underneath the last; the WAV ones were fixed because #450's own changes made them reachable or were needed for its changes to be correct. These two are not touched by it.

Testing note

None of this can be caught by the current suite — Package.swift cannot compile AudioProcessor.swift (it needs AudioAnalysisData, DataPoint, Features and more), so every trim path is untested. That harness gap is #449.