[Feature request] New Agent (beta): render ask_human / Human Input forms in the standalone Agent webapp (structured HITL confirmation)

### Self Checks

- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed.
- [x] Please do not modify this template :) and fill in all the required fields.

### 1. Is this request related to a challenge you're experiencing? Tell me about your story.

Our assistant performs **write operations** on an external SaaS system with a PREPARE → user confirmation → EXECUTE safety model. On Chatflow we could use the **Human Input node**: the webapp renders a real form widget (fields + action buttons) driven by the `human_input_required` SSE event, and the workflow resumes via `POST /form/human_input/`. Structured, deterministic confirmation.

We now also run the assistant as a **standalone new Agent app** (mode `agent`, beta, self-hosted **1.17.0**). There, the only HITL mechanism is `dify.ask_human` — which, as far as we can read the code (#37437 / ENG-635 phase 1), ends the chat turn and exposes the form through the `/form/human_input/` endpoints, while the user interaction degrades to **plain-text Q&A**: no form widget, no fields, no enforced Approve/Reject action buttons in the webapp. For a write-safety model this is a real regression — free-text replies ("yes", "ok", typos) are exactly what structured confirmation is supposed to prevent.

### 2. Additional context or comments

Source findings on 1.17.0 (the webapp side is already capable; the agent side just never sends the event):

- The shared webapp answer shell still contains the form renderer, not gated for agent apps: `HumanInputFormList` renders from `item.humanInputFormDataList` — `web/app/components/base/chat/chat/answer/index.tsx:213-224`; `renderAgentContent` only replaces the content node and does not remove the form branch (`:145-149, :272, :360`).
- SSE handlers are registered for `/agent/[token]` too, with **no `isNewAgent` gating**: `human_input_required` / `human_input_form_filled` / `human_input_form_timeout` / `workflow_paused` are handled in `web/app/components/base/chat/chat/hooks.ts:944-1016`.
- Agent-side form lifecycle already exists: `api/core/app/apps/agent_app/app_runner.py:826-852` (`_pause_for_ask_human` creates a conversation-owned HITL form and ends the turn), resume via `resolve_ask_human_form` (`app_generator.py:275`); forms are served by `api/controllers/web/human_input_form.py:152` (GET/POST `/form/human_input/`).
- Missing piece: the agent app never emits `human_input_required` into the chat SSE stream, and `AgentRosterResponseContent` only renders `thought`/`message` parts (`web/app/components/base/chat/chat/answer/agent-roster-response-content.tsx`), so a pending ask_human form is invisible to webapp users.

**Suggested solution:** when an ask_human pause occurs, emit the form payload through the existing `human_input_required` SSE event so the already-shipped `HumanInputFormList` renders in the `/agent/[token]` webapp; form submission would resolve the pending form and resume the conversation (all endpoints already exist).

Related: #37437 (ask_human HITL phase 1), #41779.

### 3. Can you help us with this feature?

- [ ] I am interested in contributing to this feature.

Start with api/core/app/apps/agent_app/app_runner.py:826-852 and app_generator.py:275 to trace the ask_human pause and resume flow, then inspect the SSE handlers in web/app/components/base/chat/chat/hooks.ts:944-1016 and AgentRosterResponseContent. Verify the existing HumanInputFormList path in web/app/components/base/chat/chat/answer/index.tsx:213-224. Done means a pending agent form appears in the standalone webapp and submission resumes the conversation through the existing form endpoints.

Written by the indexing model from the issue text.