Bug: Agent app prompt auto-generation sends app mode `agent-chat` as `model_config.mode` to `/rule-generate`

### Self Checks

- [x] I have searched for existing issues and did not find a duplicate.
- [x] I have checked the latest release/tag and main branch source.

### Dify version

Observed on a self-hosted Dify build based on `1.14.2`, and the same code path appears to still exist in upstream `1.15.0` and `main`.

### Issue Description

When using prompt/rule auto-generation in a basic Agent app, the frontend can send the app mode `agent-chat` as `model_config.mode` to `POST /console/api/rule-generate`.

The backend validates `model_config` using `core.app.app_config.entities.ModelConfig`, where `mode` is `LLMMode`. `LLMMode` only accepts `completion` or `chat`, so the request fails before rule generation starts.

### Error

```json
{
"code": "invalid_param",
"message": "1 validation error for RuleGeneratePayload\nmodel_config.mode\n Input should be 'completion' or 'chat' [type=enum, input_value='agent-chat', input_type=str]\n For further information visit https://errors.pydantic.dev/2.12/v/enum",
"status": 400
}
```

### Steps to Reproduce

1. Create or open a basic Agent app (`mode = agent-chat`).
2. Open the prompt auto-generation dialog from the app configuration prompt area.
3. Make sure there is no valid existing `auto-gen-model` stored in browser storage, or use a fresh browser/session.
4. Enter an instruction and click generate.
5. Inspect the request to `/console/api/rule-generate`.

### Actual Behavior

The request body contains:

```json
{
"model_config": {
"mode": "agent-chat"
}
}
```

The backend returns HTTP 400 because `agent-chat` is an app mode, not an LLM model mode.

### Expected Behavior

`model_config.mode` should be an LLM model mode, for example:

```json
{
"model_config": {
"mode": "chat"
}
}
```

The auto-generation request should pass backend validation and continue to rule generation.

### Suspected Root Cause

In `web/app/components/app/configuration/config/automatic/get-automatic-res.tsx`, `GetAutomaticRes` initializes the local model state with the component prop `mode`:

```ts
const [model, setModel] = React.useState(storedModel || {
name: '',
provider: '',
mode: mode as unknown as ModelModeType,
completion_params: {} as CompletionParams,
})
```

For a basic Agent app, that prop is the app mode `agent-chat`.

Later, when the default model is loaded, the effect only updates `name` and `provider`, leaving `mode` unchanged:

```ts
setModel(prev => ({
...prev,
name: defaultModel.model,
provider: defaultModel.provider.provider,
}))
```

Then `generateBasicAppFirstTimeRule` posts that model state directly as `model_config`.

### Suggested Fix

Do not initialize `model.mode` from the app mode. Use the selected/current model's model mode if available, or fall back to `ModelModeType.chat`.

It would also be useful to add a regression test for `GetAutomaticRes` with `AppModeEnum.AGENT_CHAT` and empty `auto-gen-model`, asserting that `/rule-generate` receives `model_config.mode === 'chat'`, not `agent-chat`.

### Additional Context

This does not affect ordinary Chat apps in the same way because the app mode is also `chat`, which happens to be a valid LLM mode. The problem appears specifically when app mode and model mode differ, such as `agent-chat`.

Start in web/app/components/app/configuration/config/automatic/get-automatic-res.tsx by tracing GetAutomaticRes model initialization and the default-model effect. Add regression coverage for an Agent app with an empty auto-gen-model, then verify the /rule-generate request uses model_config.mode as chat rather than agent-chat.

Written by the indexing model from the issue text.