[Feature request] Webapp parity: URL-based hand-off for /chat and /agent webapps (open conversation by sys.conversation_id, optional auto-send first message)

### 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.

One coherent ask: **URL-based hand-off / deep-linking for the `/chat` and `/agent` webapps** (open a specific conversation by URL, and optionally auto-send a first message), which today only the `/chatbot` webapp partially supports.

In enterprise integrations, an external system (portal, ticketing, ITSM) needs to open the published webapp already pointed at the right place — e.g. resume a previous conversation on another device/browser, or land the user in a conversation whose first message is composed from external context. On self-hosted **1.17.0**:

- Only `/chatbot/[token]` supports `sys.conversation_id` + `sys.user_id` URL params (gzip+base64): consumed at `web/app/components/base/chat/embedded-chatbot/hooks.tsx:86-92`, taking priority over localStorage (`web/app/components/base/chat/storage.ts:132-137`).
- `/chat/[token]` (Chatflow) and `/agent/[token]` (new Agent) only consume `sys.user_id` (`web/app/components/base/chat/chat-with-history/hooks.tsx:168-172`); conversation selection is localStorage-only (`storage.ts:67-110`, keyed by appId+userId). A conversation therefore **cannot be re-opened across browsers/devices or via a link**.
- No webapp supports auto-sending a first message from URL context, so even "land with a composed message" is impossible without forking the frontend.
- The docs state that conversations initiated via the Service API are isolated from webapp conversations, so a server-side hand-off currently has no supported landing path either.

This blocks the standard "external system → user continues in the published webapp" flow for Chatflow and new Agent apps.

### 2. Additional context or comments

- The embedded chat bubble already documents `systemVariables: { user_id, conversation_id }` (docs: *Publish → Web App → Embedding in websites*), so the concept exists for the embedded surface; the full-page `/chat` and `/agent` webapps are the gap.
- `getProcessedSystemVariablesFromUrlParams` (`web/app/components/base/chat/chat/utils.ts:48-68`) already decodes all `sys.*` params for these routes — only the consumer destructures `user_id` (`chat-with-history/hooks.tsx:168-172`).

**Suggested solution:**
1. Consume `sys.conversation_id` in `useChatWithHistory` the same way `useEmbeddedChatbot` does (validate ownership, fall back gracefully).
2. Optionally, an app-level opt-in "allow URL-composed first message" (e.g. `sys.query`), auto-invoked once after inputs/validation are ready — this covers portal hand-offs where the external system composes the opening message.

Related: #41779 (external input variables for standalone Agent apps).

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

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

Start with web/app/components/base/chat/chat-with-history/hooks.tsx:168-172 and compare it with web/app/components/base/chat/embedded-chatbot/hooks.tsx:86-92. Read web/app/components/base/chat/chat/utils.ts:48-68 and web/app/components/base/chat/storage.ts:67-110, then trace how the /chat and /agent entry points initialize inputs and conversations. Done means the requested URL hand-off behavior is defined and works without breaking localStorage fallback, with optional first-message behavior covered if included.

Written by the indexing model from the issue text.