docs(android): give ReportHandler its own page

[krassx]

setReportHandler was covered in two places — a long section inside Manual reporting → Bug reporting, and most of the Privacy → Report page. That buried an API which applies to every report, not just manually filed ones, and left two copies to drift apart.

What moved

New top-level Android page: Report handler, placed in the nav directly after the Manual reporting category — top level rather than inside it, because the handler runs for crashes, handled errors, silent uploads and bug reports alike.

• Bug reporting keeps the ## Customize reports with ReportHandler heading (so existing links still land) and now points at the new page.
• Privacy and report fields keeps its scrubbing angle and example, and defers the contract instead of restating it.
• Crash & error reporting and docs/index.md relinked.

Two things the old text never said

Both from BugseeIssueReportingCoordinator, and both affect whether a handler is correct:

1. Non-terminating callbacks run on the main thread (invokeHandlerAsync → runOnMainThread). The existing examples had readers calling openStream() and writing a config snapshot right there — file I/O on the UI thread, with a 30-second budget behind it. The page now states the thread and shows the background-thread form, which works precisely because the pipeline waits for completionCallback.

2. The terminating path differs in every respect worth knowing. It runs on an already-alive background thread, is capped at a few seconds (TERMINATING_HANDLER_CAP_MILLIS), completionCallback no longer gates anything, work scheduled for later is lost with the process, and ReportHandlerCallbackTimeout does not apply. The examples now branch on isTerminating first.

Also newly documented: a handler that throws is caught and logged, and the pipeline advances so the report still ships.

The attachment quota

I dropped the "3 attachments × 3 MB" line rather than carrying it into the canonical page. Those are 6.x figures from AttachmentsHelper, which no longer exists at that path in 7.x. The only cap I can find in the 7.x source is a soft 1000-attachment ceiling in IssueReport.createAndAddAttachment, which logs a warning and returns an attachment that is not added to the report — that is what the page now documents, along with advice to keep attachments small.

I could not find a size limit in the SDK or in the appserver config. If one is enforced server-side, it should go back in with a source — flagging rather than guessing, since the old number may simply have been stale. The same claim still appears in migration.mdx; I left it there because that page is describing the 6.x→7.x transition, but it is worth a second look.

Verification

• npx cspell — 294 files, 0 issues.
• npm run build — zero broken links and zero broken anchors. The move initially broke two #attachments references (one on the home page, one inside bug-reporting.mdx); both are retargeted, and the rebuild is clean. Worth noting this repo sets onBrokenAnchors: 'warn', so those would not have failed CI — I checked the warning output.
• Confirmed in the built output that the new page renders with its #attachments anchor and that "Report handler" appears in the Android sidebar.

🤖 Generated with Claude Code