Confirming a report was actually resolved (citizen flow)

When the responsible entity marks your report as resolved, you get one chance to confirm it actually was. Signed-in original reporters see a "Confirm resolved" button on `/report/<reportId>` once the status is `resolved`.

What happens when you confirm:
- The report's status transitions from `resolved` to `verified`.
- A "Verified by original reporter" entry lands on the timeline.
- The jurisdiction's public scoreboard treats verified reports differently from staff-resolved reports — both count toward median TTC, but the verified ratio surfaces as a separate trust signal.
- A Verified-by-Turtini credential mints for the entity proving they closed THIS specific loop with reporter consent.

What if it isn't actually fixed:
- Don't click "Confirm resolved." Instead, submit a new report at the same location. The auto-deduplicator will recognize the same-spot pattern within 7 days and merge it into the original — but the merge bumps the upvote count and re-stamps activity, signalling that the resolution was premature.
- Optionally add a public comment on the timeline ("still broken — second visit confirms"). Comments are public; staff see them inline.

If you're not the original reporter:
- The button doesn't show for you. The verify gate keys off `submittedByUid`, not org membership. Anonymous reporters can't verify either — that's the trade-off for anonymous submission.
- You can still upvote the report, which signals to the responding org that the issue is ongoing. Upvote counts are visible to staff in the Inbox Kanban.

If the report was resolved but later reverts (same pothole returns six months later):
- Submit a new report. The auto-deduplicator's 30-day window has elapsed, so it goes through as a fresh report. The original stays in the timeline as a "previously resolved at this location" historical reference for the city.