fix(rust-sdk): recognize PCM16 audio codec

[DITlieD]

The Rust SDK returned AudioCodec::Unknown(0) when the audio-codec characteristic contained the protocol-defined PCM16 value. Add AudioCodec::Pcm16 and route ID 0 through the existing conversion used by Device::audio_codec().

Fixes #13036.

The regression exercises the public device method with a synthetic BLE read and verifies the requested service/characteristic. The expected codec IDs come from sdks/device/PROTOCOL.md. Existing codecs, unknown values and truncated reads retain their behavior. The existing Rust SDK workflow runs the new integration tests.

Compatibility: a new public enum variant requires downstream exhaustive matches to account for Pcm16. This change does not claim physical-device verification or an observed recording failure.

Validation:

• Original source: 10 tests passed; the PCM16 recognition regression failed with Unknown(0).
• Candidate: all 11 crate tests passed, including exact PCM16 classification.
• Crate formatting and Clippy passed.
• All 11 selected shared repository checks passed on the actual working-tree changes. The history check was rerun with full history and passed its 90-day declaration audit.

Product invariants affected

none

Failure class

Failure-Class: FC-mirrored-model-omits-new-member

The Rust codec enum omits a member already defined by the shared in-tree protocol. The existing AudioCodec::from_id() conversion owns classification for every Rust device caller; this patch repairs that mapping and adds behavioral coverage at its public caller, without introducing another classifier or a new guard service.

The optional USD 25 bounty proposal in issue 13036 has not been approved. This description makes no payment claim.

[DITlieD]

The three-file fix and regression coverage are ready for review. All 11 crate tests, formatting, Clippy, both required repository preflight commands, and the installed pre-push gate passed locally.

The Rust SDK workflow is awaiting approval from a maintainer; no hosted CI jobs have run yet. Could a maintainer approve the workflow run when reviewing? The public-enum compatibility note and the unapproved USD 25 proposal remain documented in the PR and issue #13036.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-08T04:30:18.137658Z	81cf4e0	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[cubic-dev-ai]

No issues found across 3 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[Git-on-my-level]

Thanks @DITlieD — verified end to end; this is a correct, well-scoped fix.

What I checked:

• sdks/rust/omi-device/src/lib.rs — AudioCodec::from_id() now maps 0 => Self::Pcm16, matching the shared protocol table in sdks/device/PROTOCOL.md (ID 0 = PCM 16-bit, 1 = PCM 8-bit, 20/21 = Opus variants). The other => Self::Unknown(other) fallthrough and the truncated-read error path in Device::audio_codec() are untouched, so unknown IDs and empty reads keep their behavior.
• sdks/rust/omi-device/tests/codec_recognition.rs — good regression design: the fake BleConnection asserts the exact GATT service/characteristic being read and panics on any write or subscribe, and the suite covers the fixed case (0), the other documented IDs (1/20/21), an unknown ID (99), and the empty read. I ran cargo fmt --check, cargo clippy --offline --all-targets -- -D warnings, and cargo test on this head locally: formatting clean, no Clippy findings, all 11 tests pass. Reverting just the two-line lib.rs change makes the new regression fail, so the coverage is genuinely tied to the fix.
• sdks/rust/omi-device/README.md — the new paragraph is accurate against the code (PCM16/PCM8/Opus/Opus FS320 IDs, Unknown(id) fallthrough, truncated-protocol error on an empty read) and consistent with PROTOCOL.md.

Notes for the merge decision:

• As the description says, AudioCodec::Pcm16 is a new public enum variant, so downstream exhaustive matches will need a new arm. That is the right call versus leaving 0 as Unknown; worth a changelog/release-notes mention if this crate gets one.
• CI has not executed on this PR yet (workflows await approval for first-time contributors). The Rust SDK workflow runs cargo test --locked on sdks/rust/** and will pick up the new test file once approved to run; my local run above covers the interim.

Nice first contribution — a clear issue report (#13036), a minimal diff, and tests that exercise the public API rather than internals.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[DITlieD]

Thanks @Git-on-my-level for checking the fix and regression. Could you confirm whether issue #13036 qualifies for the proposed USD 25 bounty, and who can approve that amount? The proposal is still unapproved; I would like to clarify eligibility before treating it as paid work.

[kodjima33]

fix(rust-sdk): adds missing PCM16(0) codec ID to AudioCodec::from_id, matches protocol doc, small scoped diff with tests, confirmed not already fixed on main. Confidence 5/5.