Fixes two related over-restriction bugs in post access control. Both are scoped as security fixes, and both are cases where WPGraphQL hid content that WordPress itself exposes on the front-end and via the REST single-post endpoint. To be clear, these are over-restrictions, not leaks.

They are fixed together because they are the same underlying logic in two gates (the connection status gate and the Model privacy gate), and the regression test for each must not regress the other.

#2819 — public custom post statuses were hidden

A post in a custom status registered with public => true (the kind of status WordPress shows on the front-end) was hidden from anonymous users, both in connections and as a single node.

• Connection gate (PostObjectConnectionResolver::sanitize_post_stati) only let publish and private through and fell every other status through to an edit_posts check, so a public custom status was stripped for anonymous and non-editor users.
• Model gate (Post::is_post_private) only treated publish as public, so any other status (including a public custom status) was marked private and the single node resolved to null.

#2859 — read_private_posts users could not see private posts

A user who can read_private_posts but cannot edit_posts could not query private posts.

• Connection gate never returned the private status for an authorized reader; the private branch only ever denied, then fell through to the edit_posts check.
• Model gate applied a blanket edit_posts check before it ever considered read_private_posts.

The fix

Both gates now apply the same rules, derived from the status object and the post type's capability object:

• publish, and any status whose public flag is true (on a public/publicly_queryable post type), are visible to everyone.
• private requires read_private_posts.
• All other statuses (draft, pending, future, trash, and custom non-public statuses) require edit_posts.

Capability checks read the post type's capability object, so custom post type capabilities (read_private_{cpt}s, etc.) are respected. The revision and auto-draft access logic is unchanged, and the owner-vs-capability precedence is preserved (a subscriber who owns a private post still cannot see it, matching the REST direction the existing tests document).

For connections spanning multiple post types, a status is allowed only if the user can query it for every post type in the connection (the most restrictive choice).

A graphql_allowed_post_stati filter is added so the queryable statuses for a connection can be adjusted by extensions.

Tests

• Public custom status is visible to anonymous users in a connection and as a single node (PostObjectConnectionQueriesTest, PostObjectQueriesTest).
• A read_private_posts user without edit_posts sees private posts, while a plain subscriber still cannot.
• A non-public custom status stays hidden from anonymous users in both paths, locking in the correct behavior from Not getting schedule (future) posts #3248 so this fix does not over-expose non-public statuses.

All four touched/adjacent suites stay green (PostObjectConnectionQueriesTest, PostObjectQueriesTest, MediaItemQueriesTest, CustomPostTypeTest, RevisionTest, PreviewTest, PreviewContentNodesTest, ContentNodeInterfaceTest). PHPCS and PHPStan (level 8) are clean.

Closes #2819
Closes #2859