fix(background_review): add read_file to review fork tool whitelist

[HeLLGURD]

Bug

The background review fork ran with a tool whitelist of memory + skills toolsets only. When authoring or patching a skill that references an existing file, the fork had no way to read that file:

• skill_manage has no
  ead_file action - calling it returned Unknown action 'read_file'
• skill_view only reads skill-internal files, not arbitrary external paths

ead_file (file toolset) was denied by the whitelist

The model either fabricated content or guessed skill_manage(action='read_file') and hit the deny-wall.

Fix

Add
ead_file to
eview_whitelist after it is built from the toolset definitions.
ead_file is read-only (size-guarded, device-path checked) - no write risk. Also update the review prompt to mention it. Supersedes stale PR #27422 which targeted the since-refactored
un_agent.py path.

Fixes #40003

[teknium1]

Thanks for identifying the current deny-wall: agent/background_review.py:806-815 still derives the review whitelist from only memory and skills, and hermes_cli/plugins.py:2135-2141 enforces it before dispatch.

Problems

• This is a filesystem-read authority expansion, not only a no-write change. read_file accepts absolute paths through tools/file_tools.py:430-464, whereas the current review contract is explicitly memory/skills-only in tests/run_agent/test_background_review_toolset_restriction.py:88-158. Please establish the intended read scope before widening that boundary.
• The PR has no regression coverage. Add a whitelist-capture test that proves read_file is allowed while write_file, patch, search_files, terminal, and delegate_task remain blocked.

This is an automated hermes-sweeper review.