[johnmatthewtennant]

Summary

Siri voices whose catalog name is a code (en-US-F, en-US-G) got human names in #401 from a hardcoded table. Their real names live in the installed asset: the build paths in its Info.plist name a build directory such as .../assets/zack_v2_dual_prompt_with_fallback/p2a (Zack) or .../assets/gigi_test_2/assets/device (Gigi).

The voice catalog now reads those paths from each installed voice's asset and takes the name from them. To keep the result safe across macOS releases:

• It accepts only a build directory directly under assets/ with more path below it, whose first word is all letters.
• Every path that names a voice must agree.
• It applies only to code-named voices. Named voices like Aaron keep their names.

When the asset is missing, unreadable or ambiguous, the name falls back as before: first to #401's names, then to Siri and the name macOS shows (Siri Voice 3).

Related issue

None.

Testing

• On this Mac, the installed assets name en-US-F and en-US-G as Zack and Gigi: with berd-call: show names for code-named Siri voices #401's fallback names removed from the build, berd-call voices list still shows both names, read from their assets. With the change as committed the list is unchanged from before it, and every other code-named voice is still Siri Voice N.
• New unit tests failed before the change and pass after:
  • A code-named voice takes its name from realistic build paths.
  • A known voice whose paths name nothing keeps berd-call: show names for code-named Siri voices #401's name.
  • Disagreeing paths fall back to Siri Voice N.
  • A named voice ignores asset paths.
• New parser test covering the paths that must not yield a name: versioned build folders like en-US-F_5028, leaf folders, single letters and leading digits.

[johnmatthewtennant]

🤖 Folded into #416 for review and merge.