deps: the libavr pin advances, and a toolchain path stops being committed

The pin moves to libavr's USI I2C rate fix and to the two override surfaces the
fan-controller port filed - a PWM solve that can be pinned, and a capture edge
that is a value rather than a template argument. The four TinySafeBoot tiers
name none of them, and no image moved.

`.vscode/settings.json` stops naming a toolchain prefix. It named
`D:/dev/libavr/local/toolchain/avr-gcc-16.1.0-mingw`: a path true of one machine
(libavr guidance rule 50) and, since the in-repo toolchain copies went, true of
none - so a window opening this folder was being pointed at a directory that
does not exist. `local/machine.cmake` is where a checkout says that, and it
already did.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.vscode/settings.json

@@ -14,14 +14,13 @@
 		"--header-insertion=never"
 	],
 
-	// The presets are the build interface; the toolchain file inside the
-	// libavr submodule is the one place the compiler is chosen. The submodule
-	// carries no local/toolchain for it to discover, so the prefix is named
-	// here, for the window that opens this folder.
+	// The presets are the build interface, and the toolchain file inside the
+	// libavr submodule is the one place the compiler is chosen. **No prefix is
+	// named here**: a committed file may not name a path that is true of one
+	// machine (libavr guidance rule 50), so the gitignored local/machine.cmake
+	// at this repository's root is where a checkout says where its toolchain
+	// is - one file, and it answers for both hosts.
 	"cmake.useCMakePresets": "always",
-	"cmake.environment": {
-		"LIBAVR_TOOLCHAIN": "D:/dev/libavr/local/toolchain/avr-gcc-16.1.0-mingw"
-	},
 	"cmake.configureOnOpen": true,
 	"cmake.options.statusBarVisibility": "compact",