`/signin/check-code` silently swallows errors from `verify()` and `resendCode()`

### 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] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general).
- [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] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
- [x] Please do not modify this template :) and fill in all the required fields.

### Dify version

web/main (uncommitted)

### Cloud or Self Hosted

Self Hosted (Source)

### Steps to reproduce

Discovered by peaks-loop code-sweep on 2026-07-02.

1. Sign in via email — Dify sends a 6-digit code to your inbox.
2. Land on `/signin/check-code`. **Throttle the network** (DevTools → Network → "Slow 3G" or block `emailLoginWithCode` POST).
3. Click **Verify**. The button silently does nothing — no toast appears. The page just stays in its prior state. Console shows `[error] ...` (from the existing `console.error(error)`).
4. Click **Resend**. Same behavior — silent failure.

The user has no idea why their click did nothing.

### ✔️ Expected Behavior

Both `verify()` and `resendCode()` failures must surface a user-visible error toast so the user knows the network call or backend rejected. The error should be translated via the existing i18n key `error.unknown` so other locales get the auto-translated fallback.

### ❌ Actual Behavior

The `/signin/check-code` page handles two async calls:

- `verify()` — submits the 6-digit code via `emailLoginWithCode(...)`.
- `resendCode()` — requests a new code via `sendEmailLoginCode(...)`.

Both wrap the call in `try/catch` but on failure only call `console.error(error)` and return. No toast appears, the page just silently stays in its prior state, and the user has no idea why their click did nothing.

**Proposed change:**

- In `web/app/signin/check-code/page.tsx`: add `toast.error(t('error.unknown', { ns: 'login' }))` after `console.error(error)` in both `verify()` and `resendCode()` catch blocks.
- In `web/i18n/en-US/login.json`: add `error.unknown` key with a user-friendly string.

**Risk:** Catch blocks only add a toast; the existing `console.error(error)` is preserved so log monitoring still picks up the failure. `verify()`'s `finally` block still resets `setIsLoading(false)` in all paths. Happy path (`ret.result === "success"`) is unchanged. No backend, schema, or migration changes.

Sister fixes: PR #38334 (backend missing-document warning in `document_indexing_task`), PR #38335 (SSO login errors).

Start with web/app/signin/check-code/page.tsx and inspect the catch blocks for verify() and resendCode(). Then read web/i18n/en-US/login.json to follow the existing login error translations. Done means both failures show the translated error.unknown toast while preserving console.error(error) and the existing successful flow.

Written by the indexing model from the issue text.