fix(perf): stop reporting an unmeasured decoder as Software

[balcsida]

The performance overlay reports Software decoding on the Tizen TV, and labels the backend ExoPlayer. Both are false. Video decodes on the TV's own SoC, outside Flutter entirely — that hardware-overlay plane is the whole reason the port exists.

Root cause

PlayerTizen.providesNativeStats is true, so stats take the _fetchAndroidStats() path. That branches on the reported player type:

if (playerType == 'mpv') { … }
else { /* Parse ExoPlayer stats format */ playerType: 'exoplayer', … }

'tizen' is not 'mpv', so it falls into the ExoPlayer parse. Three failures follow:

1. The backend is mislabelled. playerType: 'exoplayer' is hardcoded in that branch.
2. The honest answer was discarded. PlayerTizen.getStats() emitted 'videoDecoder': 'unknown', but the only reader is statsMap['videoDecoderName']. Nothing in the codebase reads 'videoDecoder' — the backend told the truth and a key mismatch threw it away.
3. Absent was rendered as software. hwdecCurrent is only populated in the mpv branch, so it is null here, and hwdecFormatted treated null exactly like mpv's 'no'.

The fix

• A 'tizen' branch that emits only what the backend actually returns. Every other metric stays null, so the overlay prints N/A rather than inventing a value.
• hwdecFormatted separates no signal from evidence of software: only mpv's own 'no' still reads as Software; null or empty now reads N/A. This is not Tizen-specific — any backend that fails to answer previously got labelled Software.
• The dead 'videoDecoder' key is removed rather than renamed. Emitting it as videoDecoderName would send hwdecFormatted down its first branch, fail the hardware-pattern match, and land back on Software.
• !isMpv meant "ExoPlayer" when there were two backends. There are three now, so the ExoPlayer-only metrics ask for isExo by name. This also stops Tizen showing a Tunneling: Off row for an ExoPlayer feature it does not have.

Why N/A and not Hardware

Capi exposes no decoder-name or hwdec API, so asserting hardware acceleration would be the same error pointing the other way. docs/tizen/ACCEPTANCE.md already requires this:

Mark unavailable decoder/renderer counters as unknown, not hardware acceleration or zero dropped frames.

Verification

• flutter analyze on the changed files — clean.
• Three tests added: Tizen reports its own type and no longer fabricates a decoder name; no hwdec signal reads as N/A; and mpv's 'no' still reads as Software, so the real signal is not lost.
• Full suite: 7,454 tests, the only failure being downloads_screen_focus_test, which reproduces on clean main and is unrelated. hwdecFormatted is shared across every backend, so the whole suite was run rather than the overlay tests alone.

Independent of #3; touches no file that PR does.

AI assistance

Written with Claude Opus 5 via Claude Code, per CONTRIBUTING.md.

🤖 Generated with Claude Code