fix(code-intelligence): consent that means what it says — polarity, receipts, read-only veto

Four review findings on the wave's own Phase 1 port, all red-first:
'consent <repo> no' recorded consent GRANTED (the CLI ignored the
argument and always wrote true) — yes|no is now required and garbage
records nothing; Sourcebot egress receipts claimed consented=true on
paths that never checked consent — the actual consent state is threaded
into every receipt, search is fail-closed on non-loopback, and the
liveness probe's receipt says truthfully that it sends no repo content;
repoPolicyVeto only honored the deny tier while gbrain refresh writes
pages — write-class ops now veto on read-only too, matching the sync
chokepoint, via one shared lib/gbrain-repo-policy-client.ts (win32
bash invocation, spawn-vs-unreadable error distinction) used by both
call sites. Also: source ids get a host+path hash (same-name repos no
longer collide), refresh timeout raised to 120s, availability probes
run concurrently at 3s, graphify status stops JSON.parsing 100MB graphs
for a count, and every ported file carries the fork MIT notice.
+15 tests across the two suites.

test/gbrain-repo-policy.test.ts

@@ -344,6 +344,7 @@ describe('gstack-gbrain-sync code stage honors the repo policy (#2140 sync path)
   });
 
   test('store exists but unreadable → fail-closed refusal, never bypassed', () => {
+    if (process.platform === 'win32' || process.getuid?.() === 0) return; // chmod semantics differ
     makeRepo();
     expect(run(['set', REPO_URL, 'deny']).status).toBe(0);
     fs.chmodSync(policyFile(), 0o000);