Access & Control tab: permission-denied subject thumbnails cause repeated error toasts, flicker, and overlapping layout #434

Symptoms

On a deployed portal, opening the Access & Control settings tab of a node that carries node-scoped access assignments produces:

1. Wild flickering of the whole tab (rows repeatedly tearing down and re-rendering).
2. Repeated error toasts, one per affected assignment row, of the form:

   Something went wrong
   Loading thumbnail for <subject>: User <viewer> lacks Read permission on <subject>

3. Partly overlapping GUI graphics — assignment cards/controls render on top of each other while the tab is flickering.

Reproduction

1. On a node N inside a space, create node-scoped access: several AccessAssignment nodes under N/_Access/ plus a _Policy (PartitionAccessPolicy) with BreaksInheritance: true.
2. The assignment subjects are users whose own user partitions the viewer has no access to (the normal case — two users can share access to N without being able to read each other's partitions).
3. As one of the assignees, open N → settings → Access & Control tab.
4. Observe flicker + repeated permission-denied toasts + overlapping cards.

Analysis

• AccessControlLayoutArea renders each assignment row via AccessAssignmentControlBuilder, which uses MeshNodeThumbnailControl pointed at the subject's node path (src/MeshWeaver.Graph/AccessAssignmentControlBuilder.cs).
• MeshNodeThumbnailView.BindData() subscribes Hub.GetMeshNodeStream(NodePath) for that subject and forwards any stream error to SurfaceError(ex, "Loading thumbnail for {NodePath}") (src/MeshWeaver.Blazor/Components/MeshNodeThumbnailView.razor.cs:53-64) — i.e. a permission-denied read is surfaced as an error toast.
• Reading another user's node is denied by design here: type-level public-read (node_type_permissions) still requires partition_access, so a subject living in a partition the viewer is not a member of can never be streamed. The thumbnail must treat this as a normal, expected state.
• The area re-composes from nodeStream.CombineLatest(isAdminStream, ...) (src/MeshWeaver.Graph/AccessControlLayoutArea.cs:65), so every upstream emission rebuilds the rows, which re-subscribes every subject stream, which re-fails, which re-toasts → the flicker/toast loop. This matches the documented storm pattern (uncaught/re-fired errors on every emission) from ErrorPropagationAndWedges.

Expected behavior

• A subject node the viewer cannot read renders a fallback card (initials avatar + subject id, which the assignment row already knows from the AccessAssignment content) — no error toast, at most one debug-level log line.
• The Access & Control tab renders stably: no teardown/re-subscribe of unchanged rows on unrelated emissions, no flicker, no overlapping cards.

Notes for the fix (root cause, not band-aid)

• Distinguish permission-denied from infrastructure errors in MeshNodeThumbnailView: denied → fallback render state; genuine faults → surface once, do not re-fire per emission.
• Review the access-tab composition so rows are keyed/stable across CombineLatest emissions instead of being rebuilt (the rebuild is what turns one denied read into a repeating toast + flicker).
• The overlapping graphics reproduce while the tab is in this rebuild loop and should be re-checked once the loop is fixed; if they persist, they are a separate layout defect of the assignment rows.