fix: semantics crash on the system-cell tooltips, and a group deleted mid-sync (#350, #356) - #357

Summary

Two unrelated robustness fixes, one commit each. Both came out of failures
observed during this batch rather than from code reading.

fix(ui) — give each system-cell tooltip its own semantics container (#350)

The Windows app died with an engine-level error and took the session with it:

[ERROR:flutter/shell/platform/common/accessibility_bridge.cc(114)] Failed to
update ui::AXTree, error: 1140 will not be in the tree and is not the new root
Lost connection to device.

Root cause, established rather than guessed. It is upstream
flutter/flutter#182444
(open, P2), diagnosed in flutter/flutter#190344 and #190431 — both still open,
so no Flutter release contains the fix and upgrading would not have helped. A
Tooltip is an OverlayPortal whose overlay is joined to its anchor by a
traversal-parent identifier. That identifier is silently dropped when the
anchor's SemanticsConfiguration is absorbed into a neighbour's; the overlay is
then serialized as an unreachable child, and the Windows embedder rejects the
entire update rather than the one node.

SystemIndicatorCell writes that recipe exactly — three adjacent Tooltips in
a ListView row — and it is on the Personeel details pane where the crash was
seen. Semantics(container: true) gives each anchor a node of its own so
nothing absorbs it.

Reproduced offline before being fixed. The regression test is a harness that
records real SemanticsUpdateBuilder traffic and replays it through the
engine's own reachability rule. It reproduces the failure deterministically
(~90 rejected updates per five-row mouse sweep) and discriminates cleanly:

The last two match the upstream reporter's own measurements, which is the check
that says the harness is modelling the real defect and not something adjacent.

Deliberately left alone: ReadOnlyLock and the settings MenuAnchors /
IconButtons. A lone anchor cannot reach this state and button-based anchors
already get their own node, so changing them would have been unverifiable churn.

fix(azure) — tolerate a group deleted between listing and member read (#356)

listGroups fans out one loadMemberIds call per group. A group deleted in the
tenant inside that window returned 404 Request_ResourceNotFound and the
exception propagated out of AzureConnector.sync, failing the whole pull.
In production that means an operator's sync dies because somebody deleted a Team
while it was running.

Both per-group member fan-outs (listGroups, loadByMailNicknames) now drop
such a group and continue, logging it in Dutch by displayName + object id with
a "N overgeslagen" clause on the summary.

The tolerance is deliberately narrow, because the failure mode of getting
this wrong is worse than the bug: a blanket catch would report an expired
token as a tenant with no groups, and the action engine reads "no Azure group"
as "create it" / "it is gone" — turning an auth error into a pile of destructive
proposals. Matching is on the Graph error code via a new
GraphException.isResourceNotFound, not on the status. Still throwing: 401,
403, 429, 5xx, a 404 with no Graph error envelope, a 404 carrying any other
code, a 404 from the listing leg itself, and a direct loadMemberIds call.

The other multi-item reads were checked and are not of this shape:
loadByEmployeeIds and loadByMailNicknames' chunk loop are $filter
collection queries where a vanished object is simply absent from the result set;
the $batch membership writes already surface per-member outcomes; getUser
already returns null on 404.

Also plumbed GraphClient.getCollection's expected predicate so a handled 404
logs as a detail rather than an error (#229) — without it a fully recovered pull
still painted the operator's log red.

How #356 was found, and why it is not a regression from #355

The develop post-merge sweep after #355 went red on the live Azure job. It was
not caused by that PR, and the evidence is worth recording because the next
reader will assume it was:

• the merged range 2b5b1ef..3be60a7 touched 22 files, none under
  packages/azure_api/;
• identical code passed the same live job on PR fix: scope the Smartschool pull, show department schools, fix shared-mail precedence (#351, #352, #354) #355 fifteen minutes earlier,
  and on PR feat: "Medewerker uit dienst" — a per-record staff departure command (#349) #353 before that;
• az ad group show --group 523cfd6a-4ba5-4cb1-9231-5bf0d66d7656 confirms the
  object no longer exists in the tenant.

So a group was enumerated and then deleted inside the sync window — live
directory state moving under a read, not repo history. The test was right to go
red; the connector was wrong to die. #356 is that fix.

Test plan

Run on the branch tip (894efc6):

• dart format --output=none --set-exit-if-changed . — clean
• dart analyze --fatal-infos --fatal-warnings — clean
• dart test packages/*/test — 1678 passed / 12 skipped
  (1658/12 at develop; +20 from [Bug] A group deleted mid-sync fails the entire Azure pull #356)
• flutter test (account_manager) — 614 passed
  (612 at develop; +2 from [Bug] App dies with an accessibility_bridge AXTree update failure ("Lost connection to device") #350)
• flutter test integration_test/app_launch_test.dart -d windows —
  147 passed, unchanged

Both fixes were verified to fail without them: #350 via the harness table above,
#356 by stashing lib/ and confirming 6 behavioural failures including the
connector sync aborting.

No live API calls were made by either worker — #356's verification is unit-level
against a fake transport, which is what its acceptance criteria asked for.

Caveats worth carrying forward

• [Bug] App dies with an accessibility_bridge AXTree update failure ("Lost connection to device") #350 removes the one place our code demonstrably hits the defect, but the
  framework bug is still live. Any future pair of adjacent bare Tooltips in
  a scrolling row reintroduces it. The new test is the tripwire.
• Green CI was never evidence of absence for [Bug] App dies with an accessibility_bridge AXTree update failure ("Lost connection to device") #350. The crash is
  timing-sensitive upstream and the integration-test driver never sweeps the
  mouse across those cells — which is exactly why the Windows integration job
  passed on feat: "Medewerker uit dienst" — a per-record staff departure command (#349) #353 and fix: scope the Smartschool pull, show department schools, fix shared-mail precedence (#351, #352, #354) #355 while the bug was live.

Closes #350
Closes #356