feat(reporting): let people report a user, a group, or a message

[bmc08gt]

Builds on #1519, which merged the shared ReportReason vocabulary. This adds the three surfaces that use it.

What lands

• User profile — a Report row above Block.
• Group profile — a Report row above Leave Chat.
• Message selection bar — a Report case on MessageCapability, for anything another participant sent.

All three open AppRoute.Messaging.Report: a top-level flow route with two steps, pick a reason and — for Something Else only — describe it. The reason list is a radio group carrying a description per reason, and its button reads "Next" for Something Else and "Submit Report" for the rest, so the second step is only ever reached when it has something to collect. ReportDescription.build from :libs:reporting does the formatting, so Android and iOS send byte-identical descriptions.

Why it is a route and not a sheet

It started as a wrap-content sheet inside the chat flow, and picking Something Else had to grow that sheet to fit a text field. That ANR'd the app. A wrap-content sheet takes its drag anchors from the content's reported height and then reads them again while placing that content, so changing the content's size while the sheet is open spins the main thread. SizeTransform and BoxWithConstraints were both tried and neither helps; the rule worth carrying forward is that nothing inside a wrap-content sheet may be sized from a measurement or animate its height.

So report moved out of the chat flow into its own route with its own ReportViewModel, which also gets its state out of ChatViewModel. Height now comes from the container, and the details step has room without anything resizing.

FullscreenSheet is the only part of this that touches shared navigation. Sheets rest at 92.5%, and the 7.5% left showing is what reads as "this is a layer over something". A route you work through rather than glance at loses room to that sliver without gaining the signal, so this one takes the full height, keeps the display's own square top corners, and insets its content past the status bar.

The capability rule

Anything a participant sent can be reported; anything the server wrote, or that no longer exists, cannot. Two consequences worth reviewing:

• Your own messages are excluded. Reporting one is not a thing anyone does, and a row that is always present is a row people stop reading.
• Report has no time window, unlike edit and delete. Those windows exist because the server enforces them; nothing in the contract limits how old a reportable message may be.

Report is ordered last in the selection bar, so on a narrow screen it is the first to collapse into the overflow rather than pushing out Reply or Delete.

Confirming the report

Submitting used to close the flow in the same frame it called submit, which left the confirmation nowhere to land: a success prompt appeared only once the sheet was gone, on whatever screen was underneath, and a failure said nothing at all because the flow — and the half-filled report — had already been dismissed.

The flow now stays up until the report is acknowledged, and the Submit button carries the send. ReportViewModel exposes LoadingSuccessState: the button spins while the report is in flight, then holds its checkmark for SuccessHoldDuration — the same beat the username-claim, name-entry and photo-selection screens wait — before the confirmation comes up. The checkmark is drawn on the frame after the state is set, so raising the prompt immediately would put a scrim over one nobody had seen.

Dismissing that prompt is what exits the flow. The success state is held rather than reset while the prompt is up, so the button reads as done instead of offering to file the same report again; CodeButton disables itself while isSuccess, and the double-submit guard reads !isIdle to cover the press after success as well as the one mid-flight. A failure goes back to idle and raises an error prompt, leaving the flow where it is with the reason still picked, so the retry is one press rather than the whole flow again.

For the prompt to be seen at all, NavMessagingEntryDecorator had to stop refusing to host bars for every sheet entry. A sheet that covers the screen now hosts its own bars, exactly as a route does; a partial sheet still defers to the route beneath it, where a bar would be clipped to the sheet or hidden behind it. The predicate is extracted as hostsBars and covered by BarHostingTest.

What running it on a phone turned up

Six fixes, one commit each. None of these were visible from the code; all of them were obvious within a minute of using the flow on a 400dp device.

• The button showed neither spinner nor checkmark. CodeButton takes its content colour and its clickability from enabled, not from isLoading or isSuccess. Left enabled, a Filled button keeps its white background, while the spinner draws in the content colour and the checkmark in a hardcoded white — both white on white — and the button went on accepting presses right through the send. Both steps now pair enabled with progress.isIdle, which is what every other confirm button in the app does.
• The spinner was still invisible, because the send beats a frame. A report is a single unary call, so the button crossfaded from its label straight to a checkmark and the send read as never having happened. MinimumLoadingDuration puts a floor under the spinner rather than a delay after it: it starts with the spinner and runs alongside the send, so a send that already outlasted it is not held back. Result.onSuccessWithDelay looks like the helper for this, but it starts its clock after the work returns, so it always waits the full duration — latency on a slow call rather than a floor under a fast one.
• The sheet disappeared in a frame instead of animating down, on every exit. Report's onExit popped the entry outright. It now hands sheetNavigator.pendingSheetDismiss an empty lambda: the scene animates the sheet out and pops the entry itself once that finishes, so onExit must not also pop, or the flow leaves with one entry more than it opened.
• Reporting from the selection bar left the message highlighted. Every other action on that bar dispatches an event whose reducer clears the selection; report only pushed a route, and because it leaves the chat entirely, nothing on the way back cleared it either. Added Event.ReportRequested.
• On a 400dp phone, copy and report collapsed into the overflow with most of the bar empty. The inline budget is a fraction of the slot the actions lay out in, and that slot is the bar less the app bar's 5dp either side. 0.35 of 390dp is 136.5dp against the 140dp that three 40dp buttons and two 10dp gaps need, so capacity came out 2 — one icon plus the menu. Raised to 0.5, which clears three buttons down to a 320dp screen, and pulled out as inlineActionCapacity so widths can be checked without laying a bar out.
• The conversation title washed a ripple across the whole bar. Its click target is the entire title row, and unboundedClickable centres an unbounded ripple on it. Swapped to noRippleClickable, which gained an optional role (defaulting to null, so no existing caller changes) so dropping the indication did not also drop Role.Button.

Each of these has a test that was confirmed failing before its fix.

Notes

• FlowNavigator.back() already exits the flow when it is called at the root — its onRootReached fires before it returns false. The KDoc said the host "should" exit, which invites if (!back()) exitCanceled(), and that exits twice. A host that pops on exit then pops one entry more than it opened, which is how leaving the first report step used to land you on the chat list. Only the doc changed; no other caller used that idiom.
• Leaving the first step is a close on the trailing edge, not a back arrow. AppBarWithTitle already places a dismiss there when the ambient FlowDismissStyle is Close, but FlowHost cannot work that out here: it decides from the outer stack depth, and report is pushed over the chat rather than opened as the sheet's first entry. The step declares the style itself, in the screen rather than the flow host, so it holds wherever the step is rendered — including under test.
• A testing trap found on the way: action_back is present in the semantics tree of every centre-titled app bar, because TopAppBarBase composes a phantom UpNavigation to reserve width, plus a second copy of the real leading icon as a measurement probe. Only one copy is ever placed, so ReportFlowTest matches on layoutInfo.isPlaced rather than on the tag alone. Asserting a tag's absence would otherwise be meaningless.
• ReportFlowTest reaches the details field by its set-text action rather than a test tag: this TextInput merges its semantics into a wrapper and does not expose the field's own modifier.
• The two selection-bar tests run at a wider qualifier than the rest of the file, so the question they ask — is Report offered at all — does not depend on how many icons happen to fit.