Bound and guard the collaborative editing document store

What does this MR do and why?

Three follow-ups requested when DocumentStore was approved in !252572 (merged), at !252572 (comment 3767041076).

• MAX_LOG_LENGTH caps what is stored, not just what is transmitted. The bound holds even when a client ignores request_snapshot.
• Compaction claims carry a token. Any subscriber can send a snapshot, so one that was never asked must not be able to truncate the log.
• replace trims the claimed prefix instead of deleting the list, so updates written while a client was building its snapshot survive. Safe because Yjs updates are idempotent.

append and replace moved to Lua because check-and-act across LLEN and LTRIM cannot be expressed in MULTI. Gitlab::ExclusiveLease sets the precedent for redis.eval.

Nothing here is reachable by a user. DocumentStore still has no caller on master — the channel that consumes it is in !253403 (merged), which is why these land separately.

Still outstanding, not blocking: #g_durability have not reviewed the Redis usage yet, per doc/development/redis.md. MAX_LOG_LENGTH bounds a document at 2000 entries, but with the channel's 1 MB per-message cap the theoretical worst case per document is still large.

References

• Store introduced in: !252572 (merged)
• Consuming channel: !253403 (merged)
• Original unsplit MR: !250607 (closed)
• Feature work item: #14367

How to set up and validate locally

Nothing to validate through the UI — no caller yet.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.