refactor/introduce IContext

[max-nextcloud]

• chore(refactor): Introduce IContext and FileContext
• chore(refactor): simplify IContext API with helper classes

Todo

Backend

• Handle sync requests with IContext.
• get text file in AttachmentService based on context.
• Fix unit tests for ApiService.
• Fix 412 resonses to push requests.
• handle saving in IContext.
• Address refactor/file service #9028 (comment)
• Address refactor/file service #9028 (comment)
• check for other requests that rely on the context.
• Migrate existing documents.
• Add index for context_type, context_id.
• Have a lazy context that does not setup the filesystem unless needed.
• always create the context on the same layer.

Frontend

• Add context arguments to createCollaborativeEditor.
• Pass these arguments to the CollaborativeEditor component as props.
• Use these props to connect.
• Provide these props when saving. We still use the documentId to save and resolve the context on the backend.

Testing

• Test with public file shares
• Check playwright tests
• Fix cypress tests
• Fix playwright print test (it's now showing the placeholder at the bottom)
• Test with collectives

Documentation

• document how to implement and register a Context

[blizzz]

So far I read up to commit chore(tweak): return first editable file early. I love your iterative style and the discipline you keep with having small, digestible and sensible commits! My impression is also that with having the abstraction layers, there are many places where it just gets cleaner, and having specific logic better capsuled!

What I stumble over is that the IContext file contains the additional classes DocumentData, SessionInfo, NewSessionData. Usually this is something we keep separate and I am not sure it will always works with autoloading? Also about fellow developer expectations. Maybe something to consider.

Maybe this is also OK, just to double check: a call to removeInactiveSessionsWithoutSteps() within the create flow was removed, and not introduced back elsewhere. Alright if intentional of course.

No biggie: new classes miss the declare(strict_types=1); statement.

Can consider to mark the new event unstable or experimental, though I am not aware of a phpdoc or internal established annotation.

[blizzz]

On my dev instance I get an error during Migration:

{
  "reqId": "miQrQfvExjkhgL8Z3V6T",
  "level": 3,
  "time": "2026-08-19T14:14:45+00:00",
  "remoteAddr": "",
  "user": "--",
  "app": "updater",
  "method": "",
  "url": "--",
  "scriptName": "occ",
  "message": "\\OC\\Updater::failure: Exception: Database error when running migration 090000Date20260817110024 for app text\nAn exception occurred while executing a query: SQLSTATE[23502]: Not null violation: 7 ERROR:  column \"context_type\" of relation \"oc_text_documents\" contains null values",
  "userAgent": "--",
  "version": "35.0.0.3",
  "occ_command": [
    "occ",
    "upgrade"
  ],
  "data": {
    "app": "updater"
  }
}

DB is postgres.

Probably happens because the column is added as NOT NULL but the rows would be empty (=> NULL). Maybe set the default to "file"?

UPDATE: same with context_id. Default to 0?