docs: document MLS runtime, concurrency, and duplicate handling

[Garzas]

---

PR Submission Checklist for internal contributors

• The PR Title

  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

• The PR Description

  • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

---

Issues

• Document MLS runtime behavior and recovery flows in a way that is easier to review across teams.

Causes (Optional)

• MLS behavior is spread across sync, send, recovery, and repair paths, so understanding it from code alone is time-consuming.
• Replay and state-drift scenarios are especially hard to reason about without a dedicated write-up.

Solutions

• Added MLS documentation under docs/mls/.
• Covered:
  • use cases and handlers,
  • incremental sync and replay semantics,
  • runtime/concurrency timelines,
  • duplicate handling for MLSWelcome, NewMLSMessage, and MLSReset.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Test Results

4 652 tests  ±0   4 535 ✅ ±0   2m 43s ⏱️ -26s
  772 suites ±0     117 💤 ±0 
  772 files   ±0       0 ❌ ±0 

Results for commit 38c86a2. ± Comparison against base commit c0e9a1a.

♻️ This comment has been updated with latest results.

[github-actions]

Bencher Report

Branch	docs/mls
Testbed	ubuntu-latest

⚠️ WARNING: No Threshold found!

Without a Threshold, no Alerts will ever be generated.

• Latency (nanoseconds (ns))

Click here to create a new Threshold
For more information, see the Threshold documentation.
To only post results if a Threshold exists, set the --ci-only-thresholds flag.

Click to view all benchmark results

Benchmark	Latency	microseconds (µs)
com.wire.kalium.benchmarks.logic.CoreLogicBenchmark.createObjectInFiles	📈 view plot ⚠️ NO THRESHOLD	940.88 µs
com.wire.kalium.benchmarks.logic.CoreLogicBenchmark.createObjectInMemory	📈 view plot ⚠️ NO THRESHOLD	351,493.01 µs
com.wire.kalium.benchmarks.persistence.MessagesNoPragmaTuneBenchmark.messageInsertionBenchmark	📈 view plot ⚠️ NO THRESHOLD	1,250,000.24 µs
com.wire.kalium.benchmarks.persistence.MessagesNoPragmaTuneBenchmark.queryMessagesBenchmark	📈 view plot ⚠️ NO THRESHOLD	20,593.81 µs

🐰 View full continuous benchmarking report in Bencher

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.93%. Comparing base (ec51422) to head (38c86a2).
⚠️ Report is 106 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3974      +/-   ##
===========================================
+ Coverage    59.92%   59.93%   +0.01%     
===========================================
  Files         1981     1982       +1     
  Lines        64084    64108      +24     
  Branches      6994     6996       +2     
===========================================
+ Hits         38400    38425      +25     
  Misses       22540    22540              
+ Partials      3144     3143       -1     

see 3 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ec51422...38c86a2. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[typfel]

May be worth looking into for resilience against duplicate event processing: https://wireapp.github.io/core-crypto/v9.3.1/kotlin/-core-crypto/com.wire.crypto/-core-crypto-context-interface/set-data.htm it allows an ID or anything other string to be stored in core crypto together when a transaction commits

[typfel]

Maybe you should also add to move side effects out of the event processing. For example if you need refresh a conversation metadata due to an event, do mark that it needs it needs to be done but the actual work outside the event processing.

Doing work like this inside event processing causes long lived CC transaction which is bad for event processing throughput.

It might also reduce the impact of processing an event twice.

[typfel]

There's some duplication going on across:
incremental-sync.md
runtime-concurrency.md
use-cases.md