Fix an issue where changing an organization’s visibility caused problems when users had forked its repositories.

[lunny]

A quick fix #37317

---

The current behavior for forks when an organization or repository is changed to private differs from GitHub.

On GitHub, when a parent repository becomes private, the fork relationship is removed, which keeps the behavior simple and avoids visibility conflicts.

I think we need a similar solution to handle cases where the parent repository becomes private while a fork remains public and the fork relationship is still preserved.

[silverwind]

A couple of observations from a review pass, all non-blocking:

1. Stale error wrap: after switching from RecalculateTeamAccesses to RecalculateAccesses, the wrap string "recalculateTeamAccesses: %w" in updateRepoForVisibilityChanged is now misleading in logs.

2. Latent behavior surfaced by this fix (probably out of scope for the backport, but worth a follow-up): the recursion still runs the makePrivate block on user-owned forks when the org goes private — marking their activities_model.Action rows is_private=true and clearing their stars — even though the fork itself remains public. As the PR description notes, the proper fix is GitHub-style fork-relationship removal; flagging so it's not lost.

3. The new test asserts the visibility change succeeds but doesn't verify the resulting access-table state on the user-owned fork. Could be worth an extra assertion so a regression in the fork branch doesn't silently pass.

---

Review written with the help of Claude Opus 4.7.