Add Weaviate Engram long-term memory layer for chat and agent apps

### Summary

Dify has no long-term/external memory layer; conversation memory is only `TokenBufferMemory` (a read-only window over the `Message` table). This proposes an **opt-in, default-off** integration with [Weaviate Engram](https://docs.weaviate.io/engram), the managed memory service.

### Motivation

Engram turns raw conversation turns into durable, scoped memories and serves them via hybrid retrieval, letting apps improve over time without growing every prompt. It's a natural fit for Dify's chat/agent apps.

### Proposed change (config-gated, default-off)

- New `ENGRAM_ENABLED` / `ENGRAM_API_KEY` / `ENGRAM_ENDPOINT` / `ENGRAM_RECALL_TOP_K` settings.
- `core/memory/engram`: a thin wrapper over the `weaviate-engram` SDK with `store()` / `recall()`. SDK imported lazily; all calls best-effort (errors logged, never raised) so memory I/O cannot break generation.
- **Store**: a `message_was_created` signal handler writes the completed user/assistant turn fire-and-forget (covers chat + agent-chat).
- **Recall**: the chat runner searches relevant memories and folds them into the prompt context alongside dataset retrieval.

Note: Engram is a managed Weaviate Cloud service, so this is a cloud client integration (API key), not a docker-compose addition.

### Scope

New `core/memory/engram` module + config + a signal handler + chat-runner recall. `weaviate-engram` added as a dependency group. Unit-tested with a mocked client.

I'd like to work on this and have a PR ready.

Start by locating the existing core/memory module, configuration settings, message_was_created signal handler, and chat runner. Review how TokenBufferMemory and dataset retrieval are wired before mapping the new opt-in integration. Done means the engram module, configuration, signal-based storage, chat-runner recall, dependency group, and mocked-client unit tests are present without memory errors breaking generation.

Written by the indexing model from the issue text.