Harden HTTP hook transport against agent-relative symlink path checks (cwd mismatch)

[amondnet]

Context

Follow-up from AI review on #53 (gemini-code-assist, HIGH). Applies to the
HTTP hook transport (POST /api/hooks/claude-code,
crates/honmoon-mgmt/src/lib.rs).

Problem

The gateway resolves the tool's file_path with tokio::fs::canonicalize, which
interprets relative paths against the gateway process's cwd — not the
agent's. When the agent (Claude Code) and the gateway run in different
directories, an agent-sent relative path (e.g. a symlink config -> .env) does
not resolve on the gateway, canonicalize fails, and the symlink-based
sensitive-path deny is silently skipped. An innocuously-named symlink can thus
bypass the PreToolUse deny.

Scope / mitigating factors (why deferred, not fixed in #53)

• Only the HTTP transport is affected. The command transport — the plugin
  default (handle_hook in crates/honmoon-cli/src/hook.rs) — runs in the
  agent's own process, so canonicalize resolves the agent's symlinks correctly.
• Secret values are still redacted. PostToolUse tokenization redacts
  detected secrets in the tool response, so a bypassed .env read still has its
  secret values tokenized. The path deny is defense-in-depth, not the only layer.
• The HTTP transport is already documented as fail-open / best-effort
  (lib.rs:115).
• No clean gateway-only fix exists: the gateway lacks the agent's filesystem
  context for relative paths.

Fix options (protocol-level)

• Have the HTTP client (plugin) send absolute paths, or include the agent's
  cwd / project_root in the payload so the gateway can resolve relative to it.
• Gateway: treat non-absolute paths conservatively for PreToolUse (e.g. surface
  that resolution was not possible) rather than silently evaluating to "not
  sensitive".

References

• PR: feat: honmoon hook CLI + /api/hooks/claude-code hook transports #53
• Review thread: feat: honmoon hook CLI + /api/hooks/claude-code hook transports #53 (comment)