fix(harness): enforce parent DENY rules for spawned subagents (#2477)

## Summary

Ensure spawned subagents cannot execute tools explicitly denied by their
parent agent.

## Problem

`SubagentDeclaration.inheritParentPermissions` defaults to `true`, but
parent DENY rules were not effective for automatically created
`HarnessAgent` subagents.

There were three causes:

1. `HarnessAgent` wraps a `ReActAgent` delegate but is not itself a
`ReActAgent`, so the existing type check skipped propagation.
2. The previous logic updated the default permission engine instead of
the child’s actual `(userId, sessionId)` slot.
3. Updating only `PermissionEngine` left `AgentState.permissionContext`
unchanged, allowing the runtime to treat the context as trivial and
bypass the engine.

As a result, a subagent could execute a tool explicitly denied by its
parent.

## Changes

- Resolve both direct `ReActAgent` children and `HarnessAgent`
delegates.
- Merge parent DENY rules into the child’s actual execution slot.
- Keep `AgentState`, the permission engine cache, and persisted state
synchronized.
- Reapply current parent restrictions when:
  - spawning a new child;
  - reusing a persistent child;
  - sending a message to an existing child.
- Preserve the child’s existing:
  - permission mode;
  - ALLOW rules;
  - ASK rules;
  - working directories;
  - local DENY rules.
- Respect `inheritParentPermissions=false`.
- Avoid adding duplicate DENY rules.
- Report automatic rule rejection as `Permission denied by rules`.

Only parent DENY rules are inherited. This change does not inherit
parent ALLOW rules, ASK rules, or working directories.

For an initially trivial child context, BYPASS mode preserves the
previous behavior for unmatched `PASSTHROUGH` tools, while explicit DENY
rules still take precedence.