Record sharing 6/14: call recordings go private

[martmull]

Sixth PR of the record-sharing stack, stacked on #25429 (in-memory twin). This is the first user-visible change of the plan and the end of the smallest slice that ships call recording privacy. Still inert until IS_RECORD_SHARING_ENABLED is turned on for a workspace.

What changes

• The standard application declares callRecording with readability PRIVATE. New workspaces get it from the sync; existing workspaces get it from the new upgrade:2-39:make-call-recording-private workspace command, since the standard application is only synced at workspace creation.
• upgrade:2-39:backfill-call-recording-shares inserts one EVERYONE / FULL share row per existing call recording (deleted ones included, rowCause APPLICATION, sourceId = the callRecording object id), in chunks of 500, idempotent through the unique index. It runs after the recordShare sync command from Record sharing 2/14: add the recordShare hidden standard object and its service #25425 and after the readability flip, and skips workspaces where either object is missing.
• The three recorder apps state who may read each recording at creation through shareWith (Record sharing 4/14: let a create state who may read the record with shareWith #25428):
  • fathom: the connecting workspace member at FULL for a personal connection (visibility: 'user'), everyone at READ otherwise (resolveCallRecordingShareWith);
  • fireflies and call-recorder: everyone at READ (workspace API key, no per-user identity).
    Updates are unchanged. Apps bump their patch version and require twenty >= 2.39.0; fathom also moves its SDK pins from 2.35.0 to 2.37.0 so its integration test can pass shareWith.

Rollout

1. Deploy 2.39 and run the 2.39 upgrade (sync recordShare object, flip callRecording, backfill shares).
2. Enable IS_RECORD_SHARING_ENABLED per workspace. Before the flag, every level behaves like OPEN, and the share rows are written but not consulted.

Things to know

• The apps CI leg that runs against the published latest server image will reject shareWith as an unknown argument until a server carrying Record sharing 4/14: let a create state who may read the record with shareWith #25428 is published. The leg that runs against this branch's server passes.
• The apps' generated client is regenerated at app build time, so the shareWith argument is typed loosely in the committed app code (__args: { data, shareWith }), in the shape the SDK generates for createOne.
• Nothing in this PR turns the flag on.

Tests

• Standard-app specs: callRecording is PRIVATE, recordShare is SYSTEM, every other standard object stays OPEN.
• Fathom unit test for the share derivation (personal connection gives the member FULL, workspace connection or missing member gives everyone READ); app integration tests updated to send shareWith.
• Integration spec for the backfill command: seeds two recordings, runs the command twice, asserts exactly one EVERYONE FULL row per recording and no duplicates.
• E2E is out of scope for this PR.

Stack

1. Record sharing 1/14: add the readability level on object metadata #25421 readability level
2. Record sharing 2/14: add the recordShare hidden standard object and its service #25425 recordShare object and service
3. Record sharing 3/14: gate reads and writes on private objects with record share rows #25426 read and write gate
4. Record sharing 4/14: let a create state who may read the record with shareWith #25428 shareWith on create
5. Record sharing 5/14: evaluate record shares in memory for events #25429 in-memory twin for events
6. This PR: call recording goes PRIVATE
7. INHERITED objects follow their parent (next)

---

Generated by Claude Code

[martmull]

CI note on the (dockerhub-latest) legs of ci-twenty-apps (fathom, fireflies, call-recorder): they fail at dev sync with App requires Twenty server >=2.39.0 but this workspace has only completed the upgrade to 2.38.0. That leg runs the app integration tests against the published latest server image, which is 2.38 and does not carry the shareWith argument from #25428, so the apps in this PR cannot pass against it either way (without the engines.twenty bump they would fail on the unknown argument instead). The (local) legs build the server from this branch and are the ones that validate the change. The dockerhub legs will go green on their own once a 2.39 server image is published; there is no change in this PR that can make them pass before that, so I am not re-running them.

---

Generated by Claude Code