v4.22.1

- Fix crash when RESTORE … REPLACE targets a live graph (#3176, fixes #259 and #2506)
RESTORE decodes a payload before Redis evicts the value it replaces, so the old graph was still registered under its name. The decoder reused that live graph context instead of building a fresh one, which re-added the existing schema (crashing in Index_SetLanguage on an indexed graph — the #2506 signature) and handed the still-referenced graph back to Redis as the "new" value, double-freeing it on the background free thread (the #259 crash). The decoder now only continues into an existing graph while it is genuinely mid multi-key load; otherwise it builds a fresh graph. The legitimate multi-key RDB / replication load path is preserved.

- Reject truncated RDB payloads gracefully (#3141)
A short read — a diskless-replication stream dropping mid-transfer, a truncated RESTORE/MIGRATE payload, or a corrupt dump.rdb — previously panicked the server, or in release builds silently built a corrupt graph. FalkorDB now declares REDISMODULE_OPTIONS_HANDLE_IO_ERRORS and checks for truncation at every count and loop in the decoders, so RESTORE replies with an error and an RDB load or diskless sync is refused, with no crash and no leaked graph.
- Fail cleanly on malformed RDB payloads (#3329)
Builds on the short-read work with a centralized decode-failure path (the "long-jump" landing pad): every structural check — unknown type tags, out-of-range entity/schema/index/constraint fields, counts that overrun their buffers, GraphBLAS-rejected matrices/tensors — now aborts the decode with a single logged reason (Failed loading graph key '<key>': <reason>) instead of asserting (debug) or corrupting memory (release). v14 index decoding now also rejects vector fields it cannot represent.