Allow `hashline_edit` to optionally operate on files outside the project directory/worktree

[raphaelbahat]

Summary

Currently, hashline_edit's execute function unconditionally rejects any path whose resolved real path (via realpathSync) doesn't fall within context.directory or context.worktree, using the isWithin boundary check. This applies both to existing files and to new files by checking their parent directory. There's no way for a user/agent to intentionally edit files outside the workspace (e.g. via a config file, and so on in trusted sandboxes).

Motivation

Some legitimate workflows require editing files outside the immediate project worktree — e.g., a ~/.config file, a monorepo sibling package not included in the worktree, or a shared library the agent has explicit permission to touch. Currently, all of these fail with Access denied: "<path>" resolves outside the project directory.

Proposed Solution

Add a new opt-in config flag, e.g., allowOutsideWorkspace: boolean (default false), to HashlineConfig. This would be threaded through resolveConfig and createHashlineEditTool(config, cache), similar to how other settings like maxFileSize and exclude are already resolved and passed.

When config.allowOutsideWorkspace === true, the isWithin check in execute would be bypassed (or simply short-circuited to true), while still preserving:

• Symlink resolution via realpathSync for accurate path reporting.
• The Windows drive-root/UNC-root protections.
• Existing size (maxFileSize) and hash/fileRev integrity checks.

Acceptance Criteria

• New allowOutsideWorkspace config option (default false, preserving current behavior).
• When enabled, hashline_edit no longer throws Access denied for out-of-workspace paths.
• Windows root protections remain enforced even when the flag is enabled.
• Tests added/updated alongside the existing boundary tests to cover both the default-blocked and opt-in-allowed cases.
• Documentation update describing the security implications of enabling this flag.

Security Considerations

This is an explicit trust escalation — documentation should clearly warn that enabling this flag allows the AI agent to write to arbitrary filesystem locations reachable by the process, similar in spirit to disabling a sandbox boundary.