fix(build): self-heal stale build.ninja on 'missing and no known rule'

When a dependency package under the registry is reinstalled/moved but keeps
the same version string, the build fingerprint (which does not yet cover
registry dep state) is unchanged, so the cached build.ninja is reused.
Ninja then aborts with 'missing and no known rule to make it' and the build
hard-fails, forcing the user to run `mcpp clean` by hand.

Add that signature to is_stale_ninja_failure so try_fast_build drops to a
full graph regeneration (same invocation) instead of failing — the stale
graph is rewritten against the current dep state and the build proceeds.

(Folding registry dep state into the fingerprint to avoid the regen entirely
is a larger follow-up; see .agents/docs/2026-06-22 §T-j.)

Author: Sunrisepeak

src/build/execute.cppm

@@ -155,7 +155,14 @@ bool is_stale_ninja_failure(std::string_view output) {
     return output.find("loading 'build.ninja'") != std::string_view::npos
         || output.find("loading build.ninja") != std::string_view::npos
         || output.find("unknown target") != std::string_view::npos
-        || output.find("manifest 'build.ninja' still dirty") != std::string_view::npos;
+        || output.find("manifest 'build.ninja' still dirty") != std::string_view::npos
+        // A cached build.ninja can reference an input (e.g. a dependency
+        // source under the registry) that moved or was reinstalled since the
+        // graph was generated — the build fingerprint does not yet cover
+        // registry dep state, so the stale graph is reused. Ninja then aborts
+        // with this signature. Treat it as stale → drop to a full regen
+        // instead of hard-failing and forcing the user to `mcpp clean`.
+        || output.find("missing and no known rule to make") != std::string_view::npos;
 }
 
 // Compile a prepared BuildContext. Shared between `mcpp build` and `mcpp run`