fix(newos4): memory-graph loads stop rewriting user data; unknown sizes say unknown

Three follow-ups from the merge review, each with the assertion that pins it.

module-memory-graph.js
- _normalizeEdges no longer mutates stored weights. It capped legacy 'failed' edges
  from 0.8 to 0.2 in memory, and the next debounced save made that permanent - an
  irreversible migration of the user's graph with no schema version. The cap moved to
  _effectiveWeight(), which ranking (showStats "Strongest relationships"), the session
  view and prune() now use; the stored record is left exactly as written.
- config.json is stamped version: 2 so a future format change can migrate deliberately.

ext/webdav.js
- the two fallback parsers emit size: null instead of 0. They cannot see the size
  column, and 0 rendered as "0 B" - the same "every file looks empty" symptom as the
  parseInt bug fixed in e639c2d, one regex miss away.
- _formatSize(null) renders '—' (unknown) rather than '0 B'; 0 still renders '0 B'.

module-aiassist.js
- the lock timeout now says what to do: "AI is still busy with another turn (waited Ns).
  Wait for it to finish, or run 'ai-stop' and retry - the running turn's lock is left
  alone." It used to be a dead-end string.

Tests: test-memory-graph 39 (T6.4 rewritten to the read-time contract: stored weight
stays 0.8, effective 0.2, success unaffected), test-webdav-sizes 28 (A14d null -> '—').
maintain 26/26, live v4.6.141: _effectiveWeight 0.2 with the edge object unchanged,
_formatSize(null) '—', '0 B' still '0 B'.

0 files changed, 0 insertions, 0 deletions