fix(cli/runtime): key dependency-staleness on corePath, not only the pyproject hash

[gadievron]

The managed Python venv is a single global path (~/.openant/venv) shared by every worktree. The
staleness check (depsStalenessAt) keyed only on pyproject.toml content, so two worktrees with
identical pyproject.toml were considered "up to date" even though the venv's editable install
(pip install -e <corePath>) pointed at whichever worktree installed last -- a binary built in
worktree B would silently import worktree A's Python source.

Introduce depsHash(corePath) = sha256(corePath + "\0" + pyproject.toml contents) and use it for both
the install baseline stamp and the staleness comparison. A change of corePath (switching worktrees)
now reads as stale and triggers a reinstall that re-points the editable install at the active source.
(hashFile remains a tested file-hash utility, no longer on the staleness path.)

Tests: internal/python/runtime_corepath_test.go (two worktrees with byte-identical pyproject but
different corePath -> the second is detected as stale; same corePath -> not stale). RED 1 failed ->
GREEN; go test ./internal/python/ ok (existing staleness + hashFile tests unaffected); gofmt + vet clean.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

[gadievron]

Closing as already resolved on current master. This fix's behavior shipped via the parser-fix-stack release (#133/#134); confirmed by independent reproduction — the original bug (reconstructed from its bug-pipeline investigation) no longer manifests on master, not merely by line-presence. Part of a full validated sweep of the open-PR corpus.