fix: move EntityPrivacyUtils back into core package

[wschurman]

Why

As discussed on #407, this moves EntityPrivacyUtils back to the core package since it's a core concept.

How

Move the files, then...

It required adding a new loader method, loadOneByFieldEqualingAsync, which loads one of a set of entities for use with the EntityEdgeDeletionAuthorizationInferenceBehavior.ONE_IMPLIES_ALL deletion permission check optimization.

It is unlikely that this method will be used too frequently in application code so I marked it as @internal, but it is still in the types same as every other method.

Test Plan

Full coverage and tests for the EntityPrivacyUtils/canViewerDelete.

[wschurman]

• feat: Add ilike and trigram similarity search to pagination #431
• feat: add includeTotal option to pagination #430
• feat: Add paginated loader to entity-database-adapter-knex #422
• fix: move EntityPrivacyUtils back into core package #429 👈 (View in Graphite)
• fix: Type idField in EntityConfiguration as TIDField #425
• fix: Use TSelectedFields for knex loader order by method #424
• feat!: Add sql template and loader method #414
• feat: add codemod for upcoming v0.55.0-v0.56.0 #413
• feat: add entity-database-adapter-knex-testing-utils containing StubPostgresDatabaseAdapter #412
• chore: add CLAUDE.md and disallow test.skip #411
• feat!: move knex loaders into entity-database-adapter-knex package #410
• chore: move knex-specific loader logic out of EntityDataManager #408 : 1 other dependent PR (#409 )
• feat!: Move knex-specific loader methods to knexLoader #407
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (be40bcf) to head (30fb9dc).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##              main      #429    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files          108       108            
  Lines        14872     15061   +189     
  Branches      1302      1318    +16     
==========================================
+ Hits         14872     15061   +189     

Flag	Coverage Δ
integration	22.31% <19.08%> (-0.09%)	⬇️
unittest	96.34% <92.94%> (-0.13%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ide]

Approved but make the docs really clear that this method usually should not be used. Otherwise it may pop in PRs and people won't know better.

[ide]

I forget, do we require orderBy and offset to be undefined vs. omitted?

[wschurman]

For this internal interface, yep. For the public method types, they can be omitted.

[ide]

In the documentation, I would make clear always to use loadByFieldEqualingAsync when the given field uniquely identifies an entity and there is guaranteed to be at most one match.

loadOneByFieldEqualingAsync is only appropriate when there is the possibility of many results that match the given fields, and we are fetching one solely for performance optimization like EntityEdgeDeletionAuthorizationInferenceBehavior.ONE_IMPLIES_ALL.

(Same docs for the non-enforcing loader.)

[wschurman]

Decided to just make it private and call via loader['loadOneByFieldEqualingAsync']. I agree that there isn't a strong-enough docblock that could make it never be used. In the future we could optionally expose a internal method of getting a data manager outside of a loader, though I think that's overkill for now and loader has the cleanest API for field translation and authorization.