この変更によってダウンローダーが製品版のVVMをダウンロードできなくなるので、最新版のmainブランチを見て製品版のVVMを使う方法がわからなくなったかもです。
ちょっとどういう運用にするか迷いますが、とりあえずダウンローダーがダウンロードできるものは製品版のままにしておくのはどうでしょう。

（将来的にはVVM置き場を別で作ったりするのもアリ。全部ダウンロードすると重いし。）

#825 (comment)と重複しますが、このPRでダウンローダから直接voicevox_fat_resouceのファイルをダウンロードするようにすることを考えています。どうでしょうか？

今の範囲でレビューしちゃったので、可能なら分けていただけると助かる思いはあります！
他にも理由は２つほどありそうでした。

• このPRは製品版コアのパッチ取得を辞めることが主目的だと思うので、VVMダウンロード方法とは独立してる
• fat_resourceの運用が定まっておらず、あとからどうせコア側の変更が必要になるかもしれない（fat_resourceのバージョン管理とか）

まあでもどうしてもそうしてほしいというレベルじゃないです。must/should/want/canのshouldから少しwant寄りくらい！

わかりました。このPRでダウンローダは手を付けないことにします。

（判断メモ）

enumで2つの種類のバイナリを想定するのではなく、別途typeを持っておく手もあると思うのですが、今のこの方法で問題ないと思いました！
こっちの方が管理しやすそうですし、いろんなところで型を判定しまくることもなさそうですし、フォークする場合はこのVvBin側を変えれば良いし！

こうしている理由としてはどちらかというと、「OnnxのVec<u8>」と「VvBinのVec<u8>」が別個の役割を持っているからですね。TSだとしても{ type: "Onnx"; onnx: Uint8Array } | { type: "VvBin"; vvBin: Uint8Array; }にする…のはちょっと冗長かもしれませんが、Rustの直和型ならこれが綺麗かなと思った次第です。

ただmanifest.jsonの方のこっちはどうしましょうかね… こっちはJSONの{ "type": "onnx", "filename": "decode.onnx" }を表しますし、VVMのZIPからの読み込み時のこともあってtypeを分離させるメリットがあるんですよね…
(追記) もし分離させるんだったらRust的な観点からはtypeじゃなくてkindとでもしたいんですが、manifest.jsonに書く内容としては、うーん

#[derive(Deserialize, Clone)]
#[serde(tag = "type", rename_all = "kebab-case")]
pub(crate) enum ModelFile {
    Onnx { filename: String },
    VvBin { filename: String },
}

あ、manifest.jsonは現状PRのModelFileのままtypeとfilenameのキーをもたせるのが良さそうだと感じました！
（しっかりわかってないのでなにか変なこと言ってるかも）

#830 をマージしたときに若干つらみが出てきてしまったので、こうしてしまいました。

#[derive(Deserialize, Clone)]
pub(crate) struct ModelFile {
    pub(crate) r#type: ModelFileType,
    pub(crate) filename: Arc<str>,
}

#[derive(Deserialize, Clone, Copy)]
#[serde(rename_all = "snake_case")]
pub(crate) enum ModelFileType {
    Onnx,
    VvBin,
}

accb03f (#825)

（ただのコメントです）
ここのフォールバックは将来必要なくなるかもですね！
まあまだ色々わからないけど。