chore: Add mise config #20

Config itself is well-formed against the mise schema ([bootstrap.apt.sources.<name>] keys uris/suites/components/key/fingerprint are the documented ones, and 04B5 4C3C DCA7 9751 B16B C6B5 2256 29DF 75B1 88BD is indeed the Debian 13/trixie archive automatic signing key), and the package list does cover everything CMakeLists.txt needs. My concerns are about it being a repository-level config: it is Debian-trixie-specific, while README advertises Arch/Fedora/Ubuntu, and nothing documents or consumes it yet (README's "use vcpkg or Conan" paragraph is now outdated, and CI still carries its own duplicate dependency list).

Config itself is well-formed against the mise schema (`[bootstrap.apt.sources.<name>]` keys `uris`/`suites`/`components`/`key`/`fingerprint` are the documented ones, and `04B5 4C3C DCA7 9751 B16B C6B5 2256 29DF 75B1 88BD` is indeed the Debian 13/trixie archive automatic signing key), and the package list does cover everything `CMakeLists.txt` needs. My concerns are about it being a *repository-level* config: it is Debian-trixie-specific, while README advertises Arch/Fedora/Ubuntu, and nothing documents or consumes it yet (README's "use vcpkg or Conan" paragraph is now outdated, and CI still carries its own duplicate dependency list).

mise.toml

					
				@ -0,0 +4,4 @@

				# Select the compiler explicitly

				[env]

				CC = "gcc-14"

[env] from a repo config applies to every contributor working in this directory, so CC=gcc-14 is exported on machines where that binary does not exist (Arch ships gcc 15, Fedora gcc, and Debian trixie's own default gcc is already 14). There the first cmake -B build fails with "CMAKE_C_COMPILER not found" instead of just using the system default.

Unless the intent is explicitly "this repo only builds on Debian trixie", I'd drop these two lines (trixie's default compiler already is GCC 14, which is what CI pins) or move them to a non-shared config (mise.local.toml, global config, or a config environment).

`[env]` from a repo config applies to every contributor working in this directory, so `CC=gcc-14` is exported on machines where that binary does not exist (Arch ships `gcc` 15, Fedora `gcc`, and Debian trixie's own default `gcc` is already 14). There the first `cmake -B build` fails with "CMAKE_C_COMPILER not found" instead of just using the system default. Unless the intent is explicitly "this repo only builds on Debian trixie", I'd drop these two lines (trixie's default compiler already is GCC 14, which is what CI pins) or move them to a non-shared config (`mise.local.toml`, global config, or a config environment).

mise.toml

					
				@ -0,0 +11,4 @@

				# main repository.

				[bootstrap.apt.sources.trixie-backports]

				uris = "https://deb.debian.org/debian"

				suites = "trixie-backports"

This source is added on any machine where apt-get exists, not only Debian trixie: mise's distro filtering only applies to ppa = … entries, and [bootstrap.apt.sources] has no os/env filter. On an Ubuntu dev box mise bootstrap would therefore wire deb.debian.org trixie-backports into /etc/apt/sources.list.d/, which is the classic way to end up with a half-Debian system (and mise never removes sources again).

At minimum worth a comment in the file / README saying this config targets Debian trixie; better, keep the backports source out of the shared config and let non-Debian users install glaze themselves.

This source is added on *any* machine where `apt-get` exists, not only Debian trixie: mise's distro filtering only applies to `ppa = …` entries, and `[bootstrap.apt.sources]` has no `os`/`env` filter. On an Ubuntu dev box `mise bootstrap` would therefore wire `deb.debian.org trixie-backports` into `/etc/apt/sources.list.d/`, which is the classic way to end up with a half-Debian system (and mise never removes sources again). At minimum worth a comment in the file / README saying this config targets Debian trixie; better, keep the backports source out of the shared config and let non-Debian users install glaze themselves.

mise.toml

					
				@ -0,0 +16,4 @@

				key = "https://ftp-master.debian.org/keys/archive-key-13.asc"

				fingerprint = "04B54C3CDCA79751B16BC6B5225629DF75B188BD"

				[bootstrap.packages]

This duplicates .forgejo/workflows/build.yml, which installs its own apt list, its own CMake (get-cmake ~4.2.2) and builds glaze/magic_enum from source. Two lists that must stay in sync will drift — the glaze version below already differs.

Since this config is a superset of what CI installs, the natural follow-up is to have the workflow run mise bootstrap (or mise bootstrap packages apply --yes) instead of its hand-rolled steps. Fine as a separate PR, but without it this file has no automated consumer and will rot.

This duplicates `.forgejo/workflows/build.yml`, which installs its own apt list, its own CMake (`get-cmake` ~4.2.2) and builds glaze/magic_enum from source. Two lists that must stay in sync will drift — the glaze version below already differs. Since this config is a superset of what CI installs, the natural follow-up is to have the workflow run `mise bootstrap` (or `mise bootstrap packages apply --yes`) instead of its hand-rolled steps. Fine as a separate PR, but without it this file has no automated consumer and will rot.

mise.toml

					
				@ -0,0 +22,4 @@

				"apt:g++-14" = "latest"

				# Build tools

				"apt:ninja-build" = "latest"

Nothing in the repo uses Ninja: CMAKE_GENERATOR isn't set here, the README builds with plain cmake -B build, and CI does the same. Either set CMAKE_GENERATOR = "Ninja" in [env] so the package is actually used, or drop ninja-build.

Nothing in the repo uses Ninja: `CMAKE_GENERATOR` isn't set here, the README builds with plain `cmake -B build`, and CI does the same. Either set `CMAKE_GENERATOR = "Ninja"` in `[env]` so the package is actually used, or drop `ninja-build`.

mise.toml

					
				@ -0,0 +35,4 @@

				"apt:librtmidi-dev" = "latest"

				# C++ libraries

				"apt:libglaze-dev" = "latest"

Version skew worth a thought: trixie-backports carries libglaze-dev 8.4.0, while CI builds glaze v9.1.0 from source. CMakeLists.txt has a bare find_package(glaze REQUIRED) with no version floor, so a local mise-provisioned build and CI compile against different major versions of the JSON library the config parser is built on (glz::generic, glz::read_file_json), and a v9-only API would pass CI but break every mise user.

Same class of mismatch for libmagicenum-dev (trixie 0.9.7 vs CI's v0.9.8), though that one looks harmless for the APIs used.

Suggest pinning a minimum in find_package(glaze <min> REQUIRED) and making CI install the same version this config does.

Version skew worth a thought: trixie-backports carries `libglaze-dev` 8.4.0, while CI builds glaze v9.1.0 from source. `CMakeLists.txt` has a bare `find_package(glaze REQUIRED)` with no version floor, so a local mise-provisioned build and CI compile against different major versions of the JSON library the config parser is built on (`glz::generic`, `glz::read_file_json`), and a v9-only API would pass CI but break every mise user. Same class of mismatch for `libmagicenum-dev` (trixie 0.9.7 vs CI's v0.9.8), though that one looks harmless for the APIs used. Suggest pinning a minimum in `find_package(glaze <min> REQUIRED)` and making CI install the same version this config does.