fix: add access filter and status guard to v3 publisheddata operations - #2886

Please address the comments from this code review:

## Overall Comments
- The authorization check for non-global accessors requires `PublishedDataStatus.PRIVATE`, but `getAccessBasedFilters` still allows statuses REGISTERED, PUBLIC, and AMENDED, which means users can resolve records they are then forbidden to update; consider aligning the filter with the status guard or separating lookup vs. update concerns more clearly.
- In `update`, you build an access-scoped `filter` for the initial `findOne` but then call `update` with `{ doi: id }` instead of the same filter, which could bypass the access constraints; consider reusing the access-based filter for the update operation to ensure consistent enforcement.
- The CASL ability is instantiated twice in `update` (inside `getAccessBasedFilters` and again in the method); consider computing it once and passing it into the helper to avoid redundant work and keep the access logic in one place.

## Individual Comments

### Comment 1
<location path="src/published-data/published-data.controller.ts" line_range="359-363" />
<code_context>
+      request.user as JWTUser,
+    );
+    if (ability.cannot(Action.AccessAny, PublishedData)) {
+      filter.$or = [
+        { createdBy: (request.user as JWTUser)?.username },
+        { status: PublishedDataStatus.REGISTERED },
+        { status: PublishedDataStatus.PUBLIC },
+        { status: PublishedDataStatus.AMENDED },
+      ];
+      return filter;
</code_context>
<issue_to_address>
**suggestion (bug_risk):** The `$or` filter in `getAccessBasedFilters` may be broader than needed for updates.

For callers without `AccessAny`, this filter still returns REGISTERED, PUBLIC, and AMENDED records, even though the update logic only permits modifying PRIVATE records. This can expose records that cannot be updated and yields `BAD_REQUEST` instead of `NotFound`. For update-specific endpoints, consider restricting this filter to PRIVATE records created by the user or introducing a mutation-focused variant of `getAccessBasedFilters`.

Suggested implementation:

```typescript
  getAccessBasedFilters(
    request: Request,
    doi: string,
    options?: { forMutation?: boolean },
  ) {
    const filter: FilterQuery<PublishedData> = {
      doi,
    };
    const ability = this.caslAbilityFactory.publishedDataInstanceAccess(
      request.user as JWTUser,
    );

    if (ability.cannot(Action.AccessAny, PublishedData)) {
      const username = (request.user as JWTUser)?.username;

      if (options?.forMutation) {
        // For mutation endpoints, only expose records that the user is allowed to modify
        filter.$and = [
          { createdBy: username },
          { status: PublishedDataStatus.PRIVATE },
        ];
      } else {
        // For read-only endpoints, retain broader visibility rules
        filter.$or = [
          { createdBy: username },
          { status: PublishedDataStatus.REGISTERED },
          { status: PublishedDataStatus.PUBLIC },
          { status: PublishedDataStatus.AMENDED },
        ];
      }

      return filter;
    }

    return filter;
  }

```

1. Update all mutation/update endpoints (e.g. PUT/PATCH handlers for `PublishedData`) that call `getAccessBasedFilters` to pass `{ forMutation: true }` as the third argument so they only see PRIVATE records they can actually modify.
   - Example: `this.getAccessBasedFilters(request, doi, { forMutation: true })`.
2. Ensure `PublishedDataStatus.PRIVATE` exists in the enum and is imported into this controller file if the enum is not already fully imported.
3. If there are any non-update endpoints relying on the previous `$or` behavior, verify they continue to call `getAccessBasedFilters` without the `options` parameter to retain the broader visibility (REGISTERED, PUBLIC, AMENDED, plus own records).
</issue_to_address>