fix(contributions): downloadUrl reaches a member only through the grant (#908)

[obrien-k]

Closes #908. The grill outcome is on the issue.

The leak

GET /communities/{id}/releases/{releaseId}/contributions sent every release reader each contribution's downloadUrl. A direct API caller could skip POST /contributions/{id}/access, and with it the canDownload check and the debit. The ui never read the field there.

The change

• The list drops downloadUrl from its select, for every reader. feat(reports): a report opens the release it concerns, for reports_manage (ADR-0055) #905's reportScoped ? '' : … blank goes too: there's nothing left to blank.
• The contract:
  • ReleaseContributionDetail drops the field.
  • ReleaseContribution (the release detail's contributions[]) and Contribution drop it too. Both declared it as required, but their reads never sent it.
  • GET /contributions, the uploader's own uploads and the only list that sends the field, now declares the new OwnContribution (= Contribution + downloadUrl).
• contributionDownloadUrl.spec.ts: a source scan that counts, per file, the three ways a query comes back holding the URL: a downloadUrl: true select, a contribution call with no select, and a whole-row include. The counts are checked against an allowlist where each entry has its reason.
• Docs: a Download Grant term in CONTEXT.md, an ADR-0055 amendment, and a CHANGELOG entry under ### Changed. feat(reports): a report opens the release it concerns, for reports_manage (ADR-0055) #905's unreleased entry is corrected in place.

A fact that came up while building. The grill assumed POST /contributions returned the URL to the uploader. It doesn't: contributionSelect never selects it. So the split is the inverse of the one described: Contribution loses the field, and OwnContribution adds it for the one read that sends it. The agreed principle, that a schema declares only what its read sends, is unchanged.

Verification

• New integration test: a consumer of the release's community gets no downloadUrl key. It fails on main, where it received https://example.com/kob.torrent.
• Re-planting the leak (downloadUrl: true back in the list's select) is caught by the scan spec.
• Integration files: releaseWorkbench, reportScopedRelease and ratioExemptReads pass (18 tests).
• Full unit suite: 3,709 tests pass. Lint, tsc, typecheck:test, openapi:completeness, openapi:failure-coverage and changelog:check are clean.
• ui types, generated from this branch's openapi.json before merging: OwnContribution comes out as Contribution & { downloadUrl: string }, and ui tsc reports exactly two errors. Both are listed on stellar-ui#478, the follow-up.

Filed from the grill

• Contract fields no projection sends: survey and decide on a gate #924: contract fields that no projection sends (the general class).
• Should a standing Download Grant re-reveal the URL without a new debit? #925: should a standing grant re-reveal the URL without a new debit?
• stellar-ui#478: regenerate the types.

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 47 complexity

Metric	Results
Complexity	47

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}