attestation: record the effective row limit in recertification evidence

[babltiga]

Goal

Make access-recertification evidence record the row limit that actually applies to a grantee, next to the value configured on the grant under review.

Scope guard: evidence only. The attestation workflow, certify/revoke semantics and campaign scope stay the same.

What is true today

Once #933 (PR #1083) lands, row_limit_override is enforced, but not verbatim. The effective cap is min(smallest non-null override across the user's direct + group grants, datasource max_rows_per_query, ACCESSFLOW_PROXY_EXECUTION_MAX_ROWS).

DefaultAttestationLifecycleService.toSnapshotJson (attestation/internal/DefaultAttestationLifecycleService.java:209) writes the reviewed grant's own row_limit_override into the evidence snapshot. Two cases where that is not what the user gets:

• A direct grant of 5000 on a datasource capped at 1000: the snapshot says 5000, and 1000 applies.
• A direct grant of 500 while a group grant sets 100: the snapshot says 500, and 100 applies.

A reviewer certifying "this person can fetch 5000 rows" is certifying something that isn't true, and the CSV evidence export inherits the same value.

Steps

1. Keep the per-grant row_limit_override (that grant is what's being certified), and add effective_row_limit to the snapshot, plus a row_limit_source of grant / group:<name> / datasource_cap / global_ceiling.
2. Resolve it through DatasourceUserPermissionLookupService.findFor together with the datasource descriptor's maxRowsPerQuery and the proxy ceiling. Do not re-implement the merge or the clamp. Ideally, expose the clamp that DefaultQueryExecutor.clampMaxRows applies as one shared, testable function, so evidence and enforcement can never disagree. If core: effective-permission explorer #946 lands first, reuse its effective-access resolution.
3. Add the new columns to the evidence CSV export.
4. Show both values on the reviewer's worklist row when they differ (t()-keyed), so the reviewer sees "configured 5000 · applies 1000".
5. Backend test parity: evidence for each of the four source cases, and an expired group grant contributing nothing.
6. Docs: update the evidence description in docs/03-data-model.md / docs/05-backend.md, and the recertification section on the website.

Acceptance

• The evidence snapshot and CSV report the row limit that enforcement applies, and name its source.
• The value configured on the reviewed grant is still recorded.
• No merge or clamp logic is duplicated outside the lookup service and the executor.

Follow-up to #933.