Registry publish drops a module's static web assets: every landed view pack has no wwwroot (EntityViews CSS 404 in prod; blocks the Views/Graph flip) #2221

The defect

PluginBundleEndpoints.MapPublish — the registry's module-publish endpoint — never passes a bundle's static web assets to the shelf. It calls:

ModulePublish.Validate(plugin, manifest, files, version, packagePath)   // no staticAssets
ShelveModule(accepted.Module, accepted.Files, …, minMeshVersion: …)     // no staticAssets

Every other part of the lane was already built for them: Validate takes a staticAssets parameter, Accepted carries StaticAssets, ShelveModule takes staticAssets, LandCore materializes them into the generation directory, and the CONSUMER path (PluginBundleClient.LandFromBundle) passes them correctly. Only these two arguments were missing — so every module ever published to the registry landed with assemblies and no wwwroot, and no consumer could receive assets no matter how complete the packed bundle was (a consumer never reads the producer's archive; it fetches what the shelf holds).

Evidence

Production, memex-cloud, landed generation directories (/data/modules/<name>@<gen>):

The image copy of the same pack carries 58 files including wwwroot/{Components/, _content/, MeshWeaver.Blazor.Views.styles.css, MeshWeaver.Blazor.Views.modules.json}.

The producer side is healthy — I ran the workflow's exact sequence locally on MeshWeaver.Blazor.Views (dotnet build → dotnet publish --no-build → module-pack --deps-closure): the publish output carries wwwroot/ (8 entries, incl. the scoped-CSS bundle and JS initializers) and the packed bundle's manifest declares 254 staticAssets with the tree under meshweaver/moduleassets/. So neither the RCL publish nor the packer is at fault.

Shipped user impact

https://memex.meshweaver.cloud/_content/MeshWeaver.Blazor.EntityViews/MeshWeaver.Blazor.EntityViews.styles.css → 404. EntityViews has been store-only since #2188 retired its image copy, so NumberFieldView.razor.css has not been served since that merge (the rendered page does not even reference the stylesheet). Small blast radius — one component's scoped styles — but live, and it is the same defect that would take down the whole portal's styling one step later:

This blocks the Views/Graph source flip (#2169 Phase B2). MeshWeaver.Blazor.Views.styles.css and MeshWeaver.Blazor.Graph.styles.css return 200 today only because their image copies still exist. Retiring them — the entire point of the flip — would 404 both of the portal's main stylesheets and break collocated JS (CollaborativeMarkdownView.razor.js, DocumentSourceView.razor.js), rendering the portal unstyled. The flip is on hold until this ships and the packs are republished.

Fix

The two missing arguments, through the seam the design already provides (BundleReader.ReadModuleAssets(bytes) → Validate → accepted.StaticAssets → ShelveModule), plus PluginBundlePublishAssetsTest: publishes a real bundle through the endpoint and asserts the asset exists as a file under the landed generation, with an entry-assembly control and a declares-no-assets case. A test is needed precisely because nothing else fails when assets are dropped — the publish returns 200, the entry is recorded, the module loads, pages render, just unstyled.

🚨 Republish is required after the fix

The fix does not retro-fill the shelf: every already-published pack holds asset-less bytes and must be republished to gain its wwwroot. Order for the flip: merge → republish DefaultViews/GraphViews (and the other Blazor packs) → verify the landed generation carries wwwroot → verify the stylesheet URLs 200 while the image copy is still present → only then retire the image copy.

Related: #2169 (extraction program), #2188 (retired EntityViews' image copy — where the 404 starts), #2193 §D (bake/land per consumer identity: "a landed pack must carry its static web assets" is now assertable), #2184 (moved Views/Graph onto the modules lane).