Rebuild the snapshot when bin/ or lib/ has uncommitted edits

[DenisovAV]

Editing the tool and re-running it silently executes the previous snapshot.

tool_revision() returns the git HEAD SHA when .git is present, and bin/cache/flutter-tvos.stamp holds the revision from the last successful compile. An uncommitted edit does not move HEAD, so the two match, the recompile is skipped, and the old snapshot runs. Nothing is printed. The file-hashing branch of tool_revision() would catch it, but it only runs when there is no .git — i.e. never during development.

Why not just always hash

That is the obviously correct fix, and it is what the fallback branch does. Measured here: 52 files under bin/ and lib/, ~0.61s per invocation. Paying that on every flutter-tvos command is presumably why the SHA shortcut exists in the first place.

An mtime probe answers the same question for ~9ms — -print -quit stops at the first file newer than the stamp, and the stamp is rewritten after every successful compile, so it is a reliable "we have already built this state" marker. That is the same shape as the "$ROOT_DIR/pubspec.yaml" -nt "$stamp_path" check directly above it, so it fits the file rather than introducing a new mechanism.

Verified against a real built snapshot

step	with the probe	unpatched
warm the snapshot	compiles	—
run again, no edits	no recompile	—
touch lib/tvos_plugins.dart, run	recompiles	no recompile
run again	no recompile	—

The third row is the bug: same edit, same command, and on the unpatched script the tool keeps running the stale binary.

Found while working on the 3.32.8 line — a source change appeared to have no effect, which cost a debugging cycle chasing the wrong thing.

[DenisovAV]

Folded into #70 instead — one PR rather than three. The change is unrelated to the 3.32.8 port, but it is one hunk and not worth its own review round.