Local checkout can silently go stale between sessions — force fetch/sync check before trusting reads or starting a run #785

PROBLEM — The local checkout at ~/dev/stores/pags/platform (the same folder both the orchestrator's read-only repo tools and the coder's sessions operate against) can fall behind origin/main between sessions. This happened concretely: after coder run 97903fb3 pushed commit 6da7c9a to main (issue #772), a later orchestrator session used repo_read_file/repo_find/repo_git against that same folder and found none of the newly-shipped files — they genuinely were not on disk yet, because nothing had fetched/pulled since the push. This produced a false alarm (filed as #782, since resolved: root cause was a stale checkout, not a missing feature) and wasted a full investigation cycle.

COMPOUNDING ISSUE — repo_git's log subcommand appears to ignore arguments entirely (tested with custom --format, with -1 <sha>, with --stat <sha>) and returns an identical fixed ~20-line list regardless of input. This made the staleness harder to diagnose — the tool gave no signal that anything was wrong, it just silently returned stale-looking data. Worth checking as a separate bug in the repo_git tool implementation itself, since ignoring the cmd/args and returning a canned result is dangerous beyond just this staleness scenario — any caller trusting repo_git log output could be misled the same way.

ASK — Two independent fixes:

1. ORCHESTRATOR-SIDE (read tools): repo_read_file / repo_find / repo_grep / repo_git (and any other local-checkout read tool) should have a way to cheaply signal staleness — at minimum, compare local HEAD against origin/main's HEAD (a lightweight git fetch + rev-parse comparison) and surface a warning in the response if they differ, rather than silently serving whatever happens to be on disk. This does not need to auto-pull — a caller should be told "local HEAD is N commits behind origin/main" and decide what to do, since auto-pulling on every read could itself race with a coder mid-edit.

2. CODER-SIDE (coding_loop_start / session start): every coding session/loop should pull (or at minimum fetch and check ahead/behind) at the very start, before beginning work, so it never plans a diff against a stale base. This should also run again immediately before the session ends / before the final push, as a last check that nothing else landed on main while the session ran (the repo's one-active-session-per-repo rule limits but does not eliminate this race — e.g. a human or a different tool could push directly). Report explicitly in session output if a pull/fetch found and merged upstream changes, don't do it silently.

ALSO FIX — the repo_git log argument-ignoring bug described above; a git-log implementation that doesn't respect its own arguments should not ship regardless of the staleness issue.

No code changes should be needed to "fix" this from the orchestrator's own conversational instructions — that side is a process fix (always fetch/compare before trusting a read), not a code fix. This issue is scoped to the tool-level and coder-level fixes only.