Redis-backed save/auth locks and presence for editorData

[moodyjmz]

What this is

Replaces editorDataMemory.js's per-process save/auth locks and presence
with Redis-backed equivalents, correctly shared across docservice
replicas. On a multi-replica deployment, the existing memory backend lets
two co-authors on different replicas both get granted the same save lock,
and makes presence (who's editing) invisible cross-replica.

Opt-in via services.CoAuthoring.server.editorDataStorage: "editorDataRedisLocks"; defaults to the existing editorDataMemory
behavior, so this is not a behavior change for anyone who doesn't set it.

Full design writeup: DocService/REDIS_EDITORDATA.md (problem, scope,
architecture, known gaps).

Scope

Covers save/auth locks and presence only. Block locks, messages,
save-state, force-save, and telemetry still delegate straight to
editorDataMemory, unchanged - still single-replica-only for those.

Verification

• New Jest suite (tests/unit/editorDataRedis{Locks,Presence,Keys}.tests.js)
  against a real Redis via redis-memory-server - no container needed,
  CI-portable. Replaces three ad hoc scripts that existed before this PR.
• Two independent review rounds (each: a cold read, an adversarial attempt
  to break the specific claims made in code/docs, and a security/perf
  audit), run with no shared context between passes. Confirmed findings
  were fixed with a regression test each, verified to fail against the
  pre-fix code and pass against the fix.
• The cross-replica claim itself (a joiner on one replica sees an editor
  active on another; a WOPI-level lock survives one co-author disconnecting
  while another stays active elsewhere) was verified manually against two
  real docservice replicas sharing one Redis, behind a real WOPI host. That
  setup is not a committed integration test.

Known gaps (see REDIS_EDITORDATA.md for detail)

• Owner-token locks, not fencing tokens - open, not evaluated against the
  write path.
• No committed multi-replica integration test; the cross-replica claim
  above has only been verified manually.
• No logging anywhere in this layer's Redis error paths - several failure
  modes degrade silently (correctly, per their fail-open/fail-closed
  contracts) rather than incorrectly, but invisibly. Consistent with the
  rest of this codebase's existing logging density in similar spots, not a
  regression - worth its own follow-up pass.
• One question from manual testing was never resolved either way: whether
  a WOPI-level lock reliably releases once the last real editor
  disconnects.

Marked draft for those reasons, not because the locks/presence logic
itself is in doubt.

AI use disclosure

Written with Claude Code (claude-sonnet-5) - implementation, the two
review rounds, and this description. Every commit carries an
Assisted-by: trailer; all commits reviewed and signed off by me.

[moodyjmz]

Does this close Euro-Office/DocumentServer#267? No — recording why, so it isn't assumed either way.

What that issue asks for

1. editorDataStorage: "editorDataRedis" should stop crashing the DocService with MODULE_NOT_FOUND on startup.
2. Its stated root cause: the module exists in source but is excluded from the .deb pkg build.
3. What the reporter actually wants: co-editing session state that survives a DocService restart — "session data is lost on DocService restart or timeout."

What this PR does

Adds a different backend, editorDataRedisLocks, covering save/auth locks and presence, and registers it in the pkg manifest so it does ship in the .deb. Everything else still delegates to editorDataMemory:

addLocks, addLocksNX, removeLocks, removeAllLocks, getLocks,
addMessage, removeMessages, getMessages,
setSaved, getdelSaved,
setForceSave, getForceSave, checkAndStartForceSave,
checkAndSetForceSave, removeForceSave,
addForceSaveTimerNX, getForceSaveTimer

Against each ask

1. Not fixed. "editorDataRedis" still fails after this merges — and it can't be fixed by bundling, because that file isn't in the tree to bundle. It's absent from main, from this branch, and from upstream's default branch. This PR adds a new backend name; it doesn't make the old one resolve.
2. The diagnosis no longer holds. There's nothing to un-exclude from the build. Relatedly, the stack trace on that issue blames a Common/sources/notificationService.js require of editorDataRedis which has since been removed, so the issue is stale as written rather than merely open.
3. Partially, and not the part they need. The 17 delegated methods above are still in-process memory, so a restart still drops save-state, force-save state, block locks and messages. Their "File version has changed. The page will be refreshed" symptom is a separate matter again: version status is read from the task-result table (taskResult.select → FileStatus.UpdateVersion), not from the editorData store, so no editorDataStorage value governs it.

What someone on that issue would get from this PR: a Redis-backed lock/presence store that is correctly bundled into the .deb, and cross-replica coherence for those two concerns. What they would not get is restart durability, which is the symptom the issue leads with. Different problem, adjacent module name.

Loose end noted separately: DocService/package.json still lists the nonexistent ./sources/editorDataRedis.js in its pkg manifest — deliberately left out of this PR to keep it focused, but it's the artefact that made that issue look like a packaging-exclusion bug.