thalarch-dependencylisted

# Thalarch Dependency Engineering Dependency work changes code, build behavior, and supply-chain surface. Treat it as a compatibility migration rather than a version-number edit. ## Preflight Identify: - current direct/transitive version; - version constraint and lockfile; - runtime/compiler/toolchain compatibility; - why the dependency is needed; - affected code paths and generated artifacts; - repository policy for lockfiles/vendor directories. ## Current-source rule When internet/research tools are available, use primary current documentation, release notes, changelogs, migration guides, and vulnerability advisories for version-sensitive decisions. Do not assume an API exists because a newer example online uses it; verify the exact selected version and the project's resolved graph. ## Minimal-upgrade rule - Change only the requested/required dependency set. - Avoid opportunistic mass updates. - Preserve lockfile determinism. - Do not switch package managers/build systems as part of an ordinary library upgrade. - Separate toolchain migrations from feature work when practical. ## Compatibility matrix Check as relevant: - source/API compatibility; - binary/ABI compatibility; - runtime minimums; - compiler/plugin compatibility; - serialization/schema behavior; - platform/target compatibility; - configuration/default changes; - transitive dependency conflicts. ## Verification Use repository-native dependency resolution plus targeted compile/test/static analysis an