v1.0.4 — Fix module loading failure

Critical fix

Module loading was broken on any theme that doesn't declare add_theme_support('html5', 'script').

WordPress adds type='text/javascript' to script tags in that case. The old filter prepended type="module" without stripping the existing attribute, resulting in a duplicate — the browser used the first (text/javascript) and threw a SyntaxError: import outside module on every page load.

What's in 1.0.4

Bug fixes

• Strip existing type='text/javascript' before injecting type="module" — resolves the load failure on the majority of WordPress themes
• Replace WP_Filesystem with file_get_contents in resolve_assets() — prevents silent FTP-credential prompt failures on shared hosting
• Add early <head> inline script to apply bazaar-in-shell class before paint — eliminates flash of WordPress chrome in the manage-page iframe

Registry / data model

• WareRegistry::register() now persists trust, zero_trust, health_check, jobs, settings, and search_endpoint from ware manifests
• make_index_entry() forwards trust and zero_trust to the shell so per-ware iframe sandbox permissions are set correctly

Background jobs

• JobsController::register_ware_jobs() is now called on successful install
• JobsController::deregister_ware_jobs() is now called before ware deletion

Shell UI

• Manage nav badge seeded from bazaar_outdated_wares option on boot — updates count shown without a REST round-trip
• Nav empty-state copy distinguishes "No wares installed yet" from "All wares disabled"

Manage page

• Permissions disclosure <details> accordion on each ware card with human-readable permission labels and pill-tag styling