Fix Resource API filters for Opportunities

[jmgasper]

Summary

• intersect roleId, memberId, and resolved memberHandle filters with the caller-authorized resource set
• apply exact filters before count, ordering, and pagination so registrant totals and pages are correct
• preserve anonymous Submitter-only visibility and ordinary-member visibility while continuing to reject cross-member filters with 403
• document the query and pagination contract in Swagger, TSDoc, and the service README
• add regression coverage for ordinary, anonymous, privileged, member-handle, denial, pagination, and controller/header paths

Opportunities UI contract

Use GET /v6/resources with the existing query names:

• paginated registrants: challengeId, canonical Submitter roleId, page, and perPage
• self-registration check: the same fields plus the authenticated caller own memberId

The response body remains the legacy resource array. Pagination remains in X-Page, X-Per-Page, X-Total, X-Total-Pages, navigation headers, and Link.

Security behavior

The API determines visibility first, then ANDs every requested exact filter into that candidate set. Filters cannot expand visibility. Ordinary human callers may request only their own member ID or handle; requests for another member remain forbidden.

Validation

• pnpm lint
• pnpm build
• focused database-backed Resource query/controller suite: 6 passing
• pnpm test:logger: 2 passing
• pnpm test:adapter: 5 passing
• Swagger YAML parse
• git diff --check

The complete legacy pnpm test suite was also attempted with all three local PostgreSQL databases provisioned. Its pre-existing setup path fails before Resource query fixtures are created because app-bootstrap.ts replaces native Promise with Bluebird while the current tc-core-library-js event client calls Promise.withResolvers; that setup failure cascades across the legacy database suite. The focused query/controller tests avoid event mutations and pass against deterministic PostgreSQL fixtures.