fix: hide reference details from users who cannot see them

[igboyes]

Summary

• Enforce the same visibility rule on the single-reference detail read that already applies to the reference list, so a non-admin, non-member caller gets a 404 instead of the reference's data.
• Add checkReferenceVisibility to references/data.ts, treating a hidden reference and a missing one identically to avoid leaking existence.
• Cover the new check with tests for a blocked non-member, a full administrator, and a member reached only through a group.

[linear-code]

VIR-2820

[sourcery-ai]

Hey - I've left some high level feedback:

• Consider moving the visibility check into getReferenceImpl (or a shared lower-level helper) so that all single-reference reads consistently enforce visibility without relying on each server handler to remember to call checkReferenceVisibility.
• Since checkReferenceVisibility already encapsulates the referenceVisibilityFilter and existence check, it may be worth documenting or enforcing that other code paths calling getReferenceImpl also use this helper to avoid subtle discrepancies in visibility behavior.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider moving the visibility check into `getReferenceImpl` (or a shared lower-level helper) so that all single-reference reads consistently enforce visibility without relying on each server handler to remember to call `checkReferenceVisibility`.
- Since `checkReferenceVisibility` already encapsulates the `referenceVisibilityFilter` and existence check, it may be worth documenting or enforcing that other code paths calling `getReferenceImpl` also use this helper to avoid subtle discrepancies in visibility behavior.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[igboyes]

Re: moving the visibility check into the data-layer getReference — declining, for two reasons:

1. Authorization belongs in the handler, not data.ts. Per this repo's server layering, data.ts owns pure domain/persistence and functions.ts enforces the auth floor and any row-dependent rule after the read. A visibility gate inside getReferenceImpl would push authorization down into the data layer, which the architecture deliberately keeps out of it.

2. The other getReference call sites must not apply visibility. getReference is called internally by createReference, updateReference, and setReferenceArchived as a post-mutation re-read to return the fresh row. Those have no actor and should never 404 — folding a visibility filter in would break them. So the consistency the suggestion is aiming for would actually be incorrect for the majority of callers; only the getReference server function should enforce it, which is exactly where the check lives now.

The checkReferenceVisibility helper keeps the single-row rule in one place (mirroring referenceVisibilityFilter for the list) while leaving enforcement to the handler.