fix: preserve visibility invariant when copying or moving content

[dqnykamp]

Independent of #3023 (both branch from main); the two can land in either order.

Problem

updateVisibility enforces that a child may not be less public than its parent (access/visibility.ts:76-85). copy_move.ts predates unlisted and still reasons in terms of the binary isPublic flag, so it treats an unlisted parent as private and breaks that invariant:

• Copy (copy_move.ts:656-657): visibility: desiredParentIsPublic ? "public" : "private" — copying into an unlisted folder produced a private child.
• Move (copy_move.ts:329-335): only promoted when parent.isPublic, so moving content into an unlisted folder left it private.

Practical symptom: someone holding an unlisted folder's link sees its other children but not the newly copied or moved one.

This also undermines the reachability argument that #3023 relies on, which assumes the invariant holds in the data.

Fix

Read the parent's actual visibility instead of isPublic:

• A copy inherits the parent's visibility directly. For public and private parents this is exactly the previous behavior; unlisted parents now yield unlisted copies rather than private ones.
• Moved content is raised to the parent's visibility via a new raiseVisibility helper.

Why a new helper rather than updateVisibility

updateVisibility cascades one visibility to every descendant, so it can demote. Using it here would mean that moving a folder containing a public doc into an unlisted folder silently hides that doc.

raiseVisibility promotes only content strictly below the target level, leaving anything already more public untouched. It replaces the previous setContentIsPublic call on the move path; for a public parent the outcome is identical, since nothing can be more public than public.

The library guard ("Cannot move draft from library to published folder/activity") keeps its existing scope: it fires only for a public parent. Moving a draft into an unlisted folder is not publishing it. Its content check now reads visibility rather than the legacy isPublic flag, which is equivalent since the two are kept in sync.

Testing

Three new tests in copy_move.test.ts:

• copying into an unlisted folder makes the copy unlisted, not private;
• moving private content into an unlisted folder makes it unlisted;
• moving a folder into an unlisted folder raises its private child to unlisted while leaving its public child public.

raiseVisibility skips assignments and does not re-check ownership or the public-share
criteria, matching the setContentIsPublic call it replaces: the content is following a
parent that already satisfies them.

Full API suite passes: 383 tests across 27 files.

Not addressed here

Existing rows in production may already violate the invariant, since this bug has been live. A data audit is worth doing separately. The deprecated setContentIsPublic (query/share.ts:20) is another binary-visibility path still in use.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K3bUTUym3xhuXLegDyTNZ2

[cqnykamp]

@dqnykamp Looks like there are some merge conflicts now.

How does this preserve the "public checks" invariant? If I move an inaccessible doc into a public folder, what happens?

I think what should happen is that: you get a message saying you can't move non-public content into a public folder. That's the easiest thing for us to do that preserves the invariant. If that approach ends up being too annoying, we could find other ways later.

[cqnykamp]

See comments.