Diagnose controls rendered as text

A control displayed as its own description, such as StackControl { … }, reached the escaped-text fallback after every registered view map declined it. Loading a view assembly is not proof that its map was registered, and registering a map is not proof that it accepted the particular control or skin.

The diagnostics answer those questions separately:

• MeshWeaver.Blazor.Views.ViewsExtensions records DefaultViews registered on hub at Information when the layout client aggregates its configuration. The structured fields Address, Mvid and Count identify the hub, the exact view assembly and the map count.
• MeshWeaver.Layout.Client.ViewDispatch records the platform warning when no map accepts a control. The registered map owners identify which contributors were consulted.
• MeshWeaver.Blazor.Components.DispatchView records through the escaped-HTML fallback at Information for an actual fallback render, naming Area, ControlType and HubAddress. Ordinary view dispatch remains at Debug. Unknown-skin details remain at Debug as well.
• /health includes view_packs, with the registered owners, count and root hub. An absent default pack is Degraded: controls that need that pack may fall back, while other packs can still render their controls. An absent ILayoutClient is different: controls cannot be dispatched at all. Neither case is reported as a successful render.

The registration event runs once per layout-client aggregation, not on every control. The fallback event is limited to failed view selection. These are persistent operational signals whose value is diagnosing a visible rendering defect; they are not a temporary increase in general render logging. They do not change the health endpoint's readiness behavior.

Which hub is measured

Module HubConfigurations install the view maps on the root mesh hub. Ordinary portal circuit hubs inherit its service scope, so DispatchView resolves the root ILayoutClient; the health check reads that same registration. A circuit with its own layout-client registration needs separate investigation: the root health result does not establish which maps that circuit uses.

Descriptor consumers

The fallback descriptor includes HtmlView.IsFallback, a real Blazor component parameter. Consumers can forward the entire parameter bag, including that flag, without a special filter. The flag only identifies the rendering path; it does not alter the content or its encoding.

The initial implementation put the flag in the parameter bag but stripped it only inside DispatchView. A direct descriptor host forwarded it to an HtmlView that did not declare the parameter and threw an unmatched-parameter exception. A real HtmlRenderer regression reproduced that failure; another regression reproduced the misleading no-layout-client health message. Registration and fallback tests also capture the event category, level and structured fields, and verify that a normal HTML view emits no fallback event.

These diagnostics do not repair a missing view map, an incompatible module, or a node whose latest compiled assembly was refused by its consumer. They provide the evidence for identifying that defect. A healthy registration check alone must not be used to claim the affected page works.