[Feature] Human-in-the-loop approval as a first-class, checkpointed Action primitive

### Search before asking

- [x] I searched in the [issues](https://github.com/apache/flink-agents/issues) and found nothing similar.

### Description

What problem does it solve: a common agentic pattern is pausing a workflow for a human to approve a consequential step (send this email, execute this trade, merge this change) before it continues. In most agent frameworks that pause is awkward to implement durably — you either keep the process alive and blocking (expensive, fragile across restarts) or you build your own out-of-band persistence to remember "this agent instance is waiting on approval ID X" and reconstruct it later.

What value does it bring: Flink Agents already has exactly the durable, checkpointed, keyed state that makes this pattern natural to support well, rather than as something every user reimplements. A first-class `await_approval`-style Action would: emit a distinct event/marker when reached, park the agent instance's state via the same checkpoint/recovery path #1016 is aligning across Java and Python, and resume — deterministically, from exactly where it paused — when an external approval signal arrives (e.g. via a resource/tool call, an API, or a Kafka topic keyed to the pending approval id). No blocked thread, no bespoke persistence layer per user.

This is a genuine differentiator for "agentic AI on a stream processor" specifically — durable long-lived pause/resume is something a request/response agent framework can't do nearly as cleanly, and it plays directly to Flink Agents' actual architectural strength rather than being feature-parity with something else already common elsewhere.

Do you already have a solution in mind: no PR yet — proposing the direction first, since the exact shape (a built-in Action type vs. a documented pattern built from existing primitives, how the external "approve" signal is delivered) is a design decision I'd want maintainer input on before writing code.

### Are you willing to submit a PR?

- [ ] I'm willing to submit a PR!

Start by reviewing issue #1016 and the existing checkpoint/recovery and Action primitives in Flink Agents. Clarify with maintainers whether this should be a built-in Action or a documented pattern, how approval signals are delivered, and how deterministic pause/resume should be validated before implementation.

Written by the indexing model from the issue text.