[Feature] Allow post_acting_hook to access actual acting results

## Problem Description

The default `post_acting_hook` in the official React Agent cannot access the actual tool execution result, which significantly reduces the usefulness of this hook.

In practice, this makes it hard to implement common post-acting behaviors such as:

* observing the real acting result,
* logging tool outputs,
* collecting metrics,
* auditing execution details,
* building callbacks based on the actual result of the acting phase.

The root cause is that, in the current React Agent implementation, when the acting stage does not produce structured output, the acting result passed into `post_acting_hook` is `None` instead of the actual execution result that was obtained during acting. As a result, even though the acting step may have successfully executed tools and produced meaningful results, the hook cannot inspect or use them.

This weakens the semantic value of `post_acting_hook`, because a post-acting hook is generally expected to receive the actual output of the acting phase.

## Proposed Solution

The React Agent should pass the actual acting result into `post_acting_hook`, even when no structured output is produced.

More specifically:

* if the acting phase successfully obtains a tool execution result or final result, that result should be preserved and forwarded to the post-acting hook;
* `None` should only be used when there is truly no acting result, rather than as a fallback for non-structured-output flows.

This would make `post_acting_hook` much more practical for:

* observing acting outcomes,
* implementing post-processing logic,
* logging and tracing,
* debugging,
* custom integrations based on tool execution results.

## Affected Component(s)

* [x] Engine
* [ ] Sandbox
* [ ] Common
* [ ] Tools
* [ ] Documentation
* [x] Other: React Agent hook behavior

## Alternatives Considered

A possible workaround is to override or patch the agent's acting logic manually so that the actual result is stored somewhere else and then accessed indirectly by custom logic.

However, this has several drawbacks:

* it increases implementation complexity for users,
* it breaks the expectation that `post_acting_hook` should naturally receive the acting result,
* it makes hook-based extensions less portable and harder to maintain,
* it forces users to rely on internal implementation details instead of the public hook mechanism.

Another possible workaround is to use other callbacks or custom wrappers around tool execution, but this does not fully solve the problem because these approaches are not equivalent to a real post-acting hook and may miss the final acting result context.

## Additional Context

The issue is especially visible in scenarios where users want to implement observability or result-based callbacks through the official hook mechanism.

For example, a developer may want to:

* inspect the actual tool output in `post_acting_hook`,
* record acting results for tracing or debugging,
* trigger additional logic after acting based on the returned result.

At the moment, these use cases are hard or impossible to implement cleanly because the hook receives `None` in non-structured-output cases, even though the acting phase has already produced a meaningful result.

From an API design perspective, this also makes the behavior of `post_acting_hook` less intuitive: users typically expect a "post-acting" hook to receive the real output of the acting step.