docs: Refactor journal entry for December 11, 2025, to enhance clarity on Rust tooling

- Reorganized content to improve flow, moving insights on [[Cargo/nexttest]] and its usage in personal projects to a more prominent position.
- Clarified the differences in dependency management between Rust and other languages, emphasizing the structural distinctions in handling binary tools.
- Maintained the evaluation report on linters and auto-formatters for table alignment and code blocks.

Author: codekiln

journals/2025_12_11.md

@@ -1,14 +1,15 @@
 - Added evaluation report: [[Markdown/Tool/Evaluation/Linters and Auto-Formatters for Table Alignment and Code Blocks]]
 	- [[dprint]] is a rust based autoformatter, but it's also got some involvement with [[Webassembly]] ...
-- [[Cargo/nexttest]]
-	- I've started using this in [[Person/codekiln/GitHub/langstar]].
-		- It surprised me [here](https://github.com/codekiln/langstar/pull/680#discussion_r2611003288)
-			- My question:
-				- > In python and js, tools like linters would typically be locked alongside the libraries and specified in the package manager. Does rust really differ from these that much?
-			- [[ChatGPT/Response]]
-				- `cargo-nextest` is a **binary tool** (cargo subcommand), not a Rust library. Binary tools must be installed via `cargo install`, not added to `Cargo.toml` dev-dependencies.
-				- **Yes — Rust really does differ here.** The difference is structural:
-				  - **Cargo only manages libraries you compile into your project.** `Cargo.toml` is a crate manifest, not a general dependency manifest. Unlike JS (`package.json`) or Python (`requirements.txt`), it doesn't manage binary tools.
-				  - **Rust ecosystem assumes tools are installed globally** via `cargo install`, Nix, Docker, or OS package managers. This matches systems languages like Go/C++/Zig, not Python/JS.
-				  - **Version-locking tools happens outside Cargo** via devcontainer.json, Dockerfiles, Nix flakes, CI scripts, or a `tools/` workspace crate.
-				- **Bottom line:** Cargo intentionally separates build tools from build inputs. For reproducible tooling, use devcontainer/Docker/Nix/CI scripts, not `Cargo.toml`.
+- [[Rust]] learning
+	- [[Cargo/nexttest]]
+		- I've started using this in [[Person/codekiln/GitHub/langstar]].
+			- It surprised me [here](https://github.com/codekiln/langstar/pull/680#discussion_r2611003288)
+				- My question:
+					- > In python and js, tools like linters would typically be locked alongside the libraries and specified in the package manager. Does rust really differ from these that much?
+				- [[ChatGPT/Response]]
+					- `cargo-nextest` is a **binary tool** (cargo subcommand), not a Rust library. Binary tools must be installed via `cargo install`, not added to `Cargo.toml` dev-dependencies.
+					- **Yes — Rust really does differ here.** The difference is structural:
+						- **Cargo only manages libraries you compile into your project.** `Cargo.toml` is a crate manifest, not a general dependency manifest. Unlike JS (`package.json`) or Python (`requirements.txt`), it doesn't manage binary tools.
+						- **Rust ecosystem assumes tools are installed globally** via `cargo install`, Nix, Docker, or OS package managers. This matches systems languages like Go/C++/Zig, not Python/JS.
+						- **Version-locking tools happens outside Cargo** via devcontainer.json, Dockerfiles, Nix flakes, CI scripts, or a `tools/` workspace crate.
+					- **Bottom line:** Cargo intentionally separates build tools from build inputs. For reproducible tooling, use devcontainer/Docker/Nix/CI scripts, not `Cargo.toml`.