PROD-10276: Show comments on public group activity to logged-in non-members

[rezwan-buddyboss]

PROD link: https://buddyboss.atlassian.net/browse/PROD-10276

Two-repo fix — this is the buddyboss-platform half. The active theme (buddyboss-theme) ships its own copy of the activity entry template that overrides this repo's bundled one, and needs the identical gate swap. Companion PR: buddyboss/buddyboss-theme#2816. This PR alone does not fix the bug on a site running buddyboss-theme (the standard theme for this plugin) — both PRs are required together on such a site. This PR is sufficient by itself only for a site running neither buddyboss-theme nor another theme with its own activity template override.

Issue

A logged-in member who is not a member of a Public group cannot see existing comments on that group's activity posts — no comment list, no comment count, no Comment button — on any surface: News Feed, the poster's profile timeline, the group feed, or the single-activity permalink. The same post viewed logged-out shows the comments fine, which is the inconsistency: an anonymous visitor sees more than a signed-in member who simply hasn't joined the group.

Writing a comment is correctly members-only; this ticket is specifically about viewing existing comments, which should follow the same visibility as the post itself.

Root cause

bp_groups_filter_activity_can_comment() (src/bp-groups/bp-groups-activity.php:589, hooked to bp_activity_can_comment at priority 99, inherited from BuddyPress core) returns false for any group activity — public groups included — unless the viewer is a group member or has bp_moderate. Critically, it bails out early when ! is_user_logged_in() (:591), leaving the filter's incoming value untouched — which is what produces the inconsistency: a logged-out visitor never hits the membership veto at all, while a logged-in non-member always does.

Every entry template then gates the entire comments block — the existing comment list, the count, and the write form — behind that single bp_activity_can_comment() check, conflating two different permissions ("can I see what's already here" vs. "can I add to it") into one boolean.

Fix

Split "can view" from "can write" instead of changing the membership check itself:

• Added bb_activity_can_view_comments( $activity ) and its reply counterpart bb_activity_can_view_comment_replies( $comment ) (src/bp-activity/bp-activity-template.php). Each starts from the existing bp_activity_can_comment() / bp_activity_can_comment_reply() result, and only for a group activity that the viewer can already read (bp_activity_user_can_read()), temporarily unhooks bp_groups_filter_activity_can_comment[_reply] to recompute the value without the membership veto. The membership check itself is untouched — this only decides whether it gets applied to the view-permission question.
• Swapped every display-only bp_activity_can_comment() / bp_activity_can_comment_reply() call site to the new bb_activity_can_view_comments() / bb_activity_can_view_comment_replies() — the comments-block wrapper in both Nouveau templates (buddypress/activity/entry.php, readylaunch/activity/entry.php), the ReadyLaunch comment-reply block (readylaunch/activity/comment.php), the has-comments CSS class helper, the RSS feed's <slash:comments> output, and the ReadyLaunch activity-state helper class.
• Every comment/reply form call site keeps the original bp_activity_can_comment() gate unchanged (in Nouveau entry.php and ReadyLaunch entry.php, now is_user_logged_in() && bp_activity_can_comment()), so posting still requires group membership through the UI.
• Added server-side enforcement so posting is blocked even if a client bypasses the UI entirely: a new bb_activity_new_comment_validate_group_membership filter plus a group-membership check directly in bp_activity_new_comment() (src/bp-activity/bp-activity-functions.php), and the equivalent check in BP_REST_Activity_Comment_Endpoint::create_item_permissions_check() for the REST path — both reject with "You need to be a member of this group to comment." if the poster isn't a member (or is banned) and lacks bp_moderate.
• Added a can_view_comments field to the REST activity response (class-bp-rest-activity-endpoint.php), separate from the existing can_comment field, wrapped in function_exists( 'bb_activity_can_view_comments' ) so older/mismatched builds degrade to the previous can_comment value rather than fatal.

Note: the commit message on this branch mentions mirroring the REST changes into buddyboss-platform-api — that repo is out of scope for this PR and is not part of this fix.