refresh: batch edits where a rebuild is slow

[swapnilpaliwal-sd]

Symptom

Every edit started the background refresher, which rebuilt after a 2 s quiet window. On a repository whose rebuild takes 20–30 s or more, an agent editing every few seconds kept a rebuild running back to back: the machine was busy rebuilding a graph that was stale again before it finished.

Change

• Once the last build took AXIOMCODE_REFRESH_BATCH_ABOVE seconds (default 20), an edit tool (Edit, Write, MultiEdit, NotebookEdit) only counts; the AXIOMCODE_REFRESH_BATCH-th edit (default 3, 1 = off) starts the rebuild. A shell command waits for the next edit or checkpoint.
• The worker's re-check after a build waits for the same batch, so edits made during a build don't start an immediate second one.
• The end of a turn, a prompt, a session start, the MCP timer and every query still refresh at once, so the graph is current whenever the agent stops or asks.
• Repositories that build faster than the threshold behave exactly as before.

Evidence

• tests/refresh.py: new checks per language with the threshold forced to 0 — two edits and a shell command start no rebuild, the third edit does, the batch starts over after it, and the end of a turn rebuilds after a single edit. The existing hook check (default threshold, every edit rebuilds) is the control. Java and Python pass.
• The 8 Java failures in tests/refresh.py and the 1 in tests/refresh_races.py fail identically on the unmodified integration branch (all changed reporting); tests/freshness.py passes.
• Real 1,300-file Java repository (rebuilds 22–33 s), replaying 6 edits 20 s apart and then the end of a turn, each run isolated (no worker left from the previous one):

	Rebuilds	Seconds rebuilding
batching off (= before)	4, 4	163, 152
batching on	2	72

A second batching-on run was invalid: the disk filled during it and the rebuild failed writing the graph (database or disk is full).