feat: モデルを追加
（HuggingFace、PRの作り方がちょっと複雑...）
モデルを追加します。
dataset.jsonlはおそらくGithub側のtrainで「これダウンロードして学習してください」と案内する感じになりそうですかね？
だとするとたぶんURLを固定したくなりそうで、dataset.jsonlだと不都合があるかも？
例えば微妙だったdatasetもこっちに置いておきたいとかありそう。
同様にmodelも一意にしたくなりそうですが、Github側から参照するときどうしましょう？
Github側から見るときはたぶんbuild時の設定URLとかWorkflowのenvとかになる･･･？
そこでtagを指定できたり、あるいはコミット番号を指定できるならそれでも良い･･･？
どうすべきとかわからないのですが一旦コメントまで！
とりあえずmodel.pthだけ置いといて、データセットの整備はあとでとかでもありだと思います。
データセットはちゃんと管理するなら別でデータセットリポジトリを作った方がいいと思います。
というのも、こんな感じにしっかりした表示ができるんですよね： https://huggingface.co/datasets/sevenc-nanashi/kiiteitte
モデルは…どうしよう。
最初はGit Tagで管理するような構想だったけどよくよく考えたらたとえばdim=128版みたいなのを作る時にそれだと不便か…でも低精度版作るかどうか…
あ、構想の予定とか、このプルリクエストが合っているかを判断するのに必要な内容はあらかじめ書いといていただけると助かります！
datasetに関してはなるほどです。
こっちはとりあえず置いてるだけって感じですかね？
git tagなるほどです！
これweb上からはどのcommitにタグ付いてるか見えなかったり･･･？
それともここで選べるのかな
web上のどこからも見れないとなるとちょっと不便ではありそう。
かといってcommit番号指定も難しそう･･･そして名前を一意にして一生管理するのもしんどそう････う〜む。
低精度高速版をどうするかは一旦さておいても良いかも？
容量的に問題ないなら２つ入れちゃっても良いかもですね！ PNGのquarity引数みたいな感じで。
まあとりあえず１つでも良さそう感。
どうやら黄色い背景でタグを出してくれるっぽそう。
こっちはとりあえず置いてるだけって感じですかね？
ですね。そのうちちゃんとデータセットでリポジトリ作るとかも必要になってくるかも？
容量的に問題ないなら
brotliかけて3.7MBくらいですね。
PyPIの容量制限とかも見たほうがよさそう。
どうやら黄色い背景でタグを出してくれるっぽそう。
あ、ならタグで良い気がしました！
バージョニングどうするか悩むけど･･･。
もしかしたらメジャー・マイナー・パッチじゃなくて整数バージョン１つだけで良いのかもしれない。（適当）
ですね。そのうちちゃんとデータセットでリポジトリ作るとかも必要になってくるかも？
了解です！
他の人が同じデータセット使って再現実験できるくらいにはGithubを整備しておきたいですね。
（このドキュメント整理が３年後の自分を救う）
Rustもbuild.rsで落とせば実質無視できそう。
それもそうかもです。
まあちょっとシグネチャとか整理するの大変なので、一旦品質ごとに頑張るのは後回しにして、先にe2k完成させるのが良い気がしています。
@sevenc-nanashi さん的に複数モデルが優先度高めなら先にそっち整備しても良いかも。
もしかしたらメジャー・マイナー・パッチじゃなくて整数バージョン１つだけで良いのかもしれない。（適当）
Misskeyとかは年.月.インクリメントでやっていました。これくらいがちょうどよさそう？（2025.3.0 -> 2025.3.1 -> 2025.4.0、みたいな）
（Pride Versioningという手もありますが）
なるほどです！
整数１つで良い気がしてましたが、僕達が管理しやすいようになにかしらわかりやすいの振っておくのも良いかもですね！
（「これくらいがちょうどよさそう」を言語化をしてみました）
Pride Versioningも面白そうですがちょっとめんどくさそう。たぶん置き換えるなんて数回だろうし･･･。
年.月.インクリメントが良さそうならそれで、別になんでも良いなら整数でどうでしょう！
なんでもいいので整数にしておきます。
LGTM！！
もしかしたら最高の形ではないかもだけど、正直よくわからないのでものは試しという感じで進めるのが良さそう感！！
マージします。タグもつけておきます。