fix: [ENG-2858] drop read-side sidecar wraps to avoid double-counting

End-to-end testing on a real project (PR #677) revealed that
SearchKnowledgeService already mirrors access hits to the sidecar via
flushAccessHits -> mirrorHitsToSignalStore inside acquireIndex's
cache-refresh path. The earlier explore-agent report missed this — it
claimed the legacy bump was missing for tool-mode, which is why we added
bumpSidecarOnQueryRead in the first place.

With both bumps active, every tool-mode read scaled accessCount by ~2x
and importance by ~2x. Observed in production:
- Before fix: brv query caused accessCount +2, importance +6 (one call)
- After fix:  brv search caused accessCount +1, importance +3 (one call,
  canonical ACCESS_IMPORTANCE_BONUS)

Topic maturity was prematurely promoting to 'core' tier as a result.

Removed:
- bumpSidecarOnQueryRead helper (no longer used)
- SearchExecutor's runtimeSignalStore ctor param + bump call
- QueryExecutor's runtimeSignalStore dep + executeToolMode wrapper
- Daemon construction sites' runtimeSignalStore arg to those executors
- All associated unit tests

Kept (essential):
- bumpSidecarOnCurateWrite — no equivalent legacy mechanism on tool-mode
  curate-html-direct or CLI curate-session writes
- All write-path wiring (agent-process.ts case, curate-session.ts)

Helper module docstring now explains why the read-side helper was
removed so a future contributor doesn't re-add it.