fix(skins): ignore subresource load errors

[ODevStudio]

Summary

What changed, and why?

• Keep the embedded skin visible when an image, script, font, or other
  subresource fails to load.
• Preserve the existing full-screen error for main-frame failures, including
  an unavailable local skin server, and keep logging every WebView load error.
• Treat an unavailable main-frame flag conservatively as a main-frame failure.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore / infra
• Plugin (DYE2 or bundled skin)

Scope (select all touched areas)

• BLE transport / device comms
• REST API / handlers
• WebSocket API
• Machine state / shot logic
• Scale / weight / flow
• Profiles / beans / grinders / workflows
• WebUI skins
• Plugins / JS runtime
• UI / Flutter widgets
• Storage / Drift database
• CI / build / infra
• Docs / specs

Linked Issues

Fixes #532

Root Cause (if bug fix)

• Root cause: The WebView error callback replaced the whole skin for every
  failed resource, not just a failed main document.
• Missing detection or guardrail: Navigation tests did not distinguish
  main-frame failures from image, script, font, or other subresource failures.
• Contributing context: Older callback metadata can omit the main-frame flag,
  which must remain a conservative fatal case.

Regression Test Plan (if bug fix or refactor)

• Coverage level that should have caught this:
  • Unit test
  • Integration test (mock transport edge)
  • End-to-end test (simulate=1 + curl/websocat)
  • Existing coverage already sufficient
• Target test or file: test/unit/skin_feature/skin_navigation_test.dart.
• Scenario the test should lock in: Subresource failures stay logged and
  nonfatal; true or unknown main-frame failures retain the full-screen error.
• If no new test added, why not: N/A; the policy test was added first.

Documentation Obligations (required)

• API spec updated: assets/api/rest_v1.yml or assets/api/websocket_v1.yml (if REST/WebSocket changed)
• API docs updated: doc/Api.md (if user-facing endpoint changed)
• Plugin docs updated: doc/Plugins.md (if events/API changed)
• Skin docs updated: doc/Skins.md (if skin behavior changed)
• Profile docs updated: doc/Profiles.md (if profile handling changed)
• Device docs updated: doc/DeviceManagement.md (if device flows changed)
• N/A - no public contract documentation changed

Security Impact (required)

• New or changed REST endpoints? No.
• New or changed WebSocket topics? No.
• New or changed network calls? No.
• BLE/USB surface changed? No.
• File system access changed? No.
• Plugin sandbox boundary changed? No.
• If any Yes, explain risk and mitigation: N/A.

User-Visible Changes

• A failed remote or optional skin resource no longer replaces an otherwise
  running skin with Decaid's full-screen error view.
• A failed main document still shows the existing error and Dashboard action.

Verification

Local gates (run before pushing)

• dart format lib test - no remaining candidate changes
• flutter analyze - clean
• flutter test - 3,179 passed, 1 skipped
• ./scripts/fetch_dye2_plugin.sh - not rerun for this local draft

Manual verification (if applicable)

• OS / platform tested: Physical Samsung Galaxy Tab A9+ SM-X210, Android 15
  (API 35), 1920x1200 landscape, mirrored through Android Studio on Windows.
• Simulated devices? (simulate=1): Yes.
• Real hardware? (DE1/Bengle/scale): No, not applicable.
• What you personally verified and how: The active Streamline skin referenced
  an intentionally unreachable HTTPS image. Android logged HOST_LOOKUP and
  ERR_NAME_NOT_RESOLVED, then completed the main page. Computer Use confirmed
  that Streamline stayed visible. A separate run pointed the main frame to an
  unused local port; Android logged CANNOT_CONNECT_TO_HOST and showed the
  existing full-screen WebView error with its Dashboard action.
• Edge cases checked: Explicit subresource, explicit main frame, and unavailable
  frame metadata.
• What you did not verify: The reporter's exact remote skin and device-wide
  DNS outage. The tablet test reproduced the same subresource error class with
  a controlled unreachable hostname.

Evidence

• Test output (failing before + passing after)
• Log snippets
• Screenshot / recording (UI changes)
• curl / websocat output (API changes)

Detailed evidence:

• The attached field log shows the API and WebUI servers starting, the
  localhost:3000 main page finishing, and successful API calls before each
  later HOST_LOOKUP event. The same interval contains device-wide DNS
  failures for github.com and api.github.com, ruling out a local server
  startup failure and identifying the fatal event as a subresource failure.
• Added the error-policy test first; it failed before the main-frame policy
  existed and passes for false, true, and unavailable frame metadata.
• flutter test test/unit/skin_feature/skin_navigation_test.dart (11 passed)
• flutter analyze (no issues)
• flutter test with the package-matched QuickJS DLL on PATH and temporary
  LF normalization for the line-ending-sensitive AsyncAPI assertion (3,179
  passed, 1 skipped)
• git diff --cached --check before commit (clean)
• Flutter's default Windows path still selected CMake 3.20, but the unchanged
  source built with installed CMake 3.28 and Visual Studio 2022. Computer Use
  verified that an intentional subresource DNS failure stays nonfatal after
  the failure has settled.
• Samsung tablet subresource run: HOST_LOOKUP at 13:55:24, followed by the
  main page finishing at 13:55:25; Streamline remained fully visible.
• Samsung tablet main-frame run: CANNOT_CONNECT_TO_HOST for
  localhost:3999; the full-screen WebView error and Dashboard action appeared.

Compatibility & Migration

• Backward compatible? Yes; only host error presentation changes.
• Config / env changes needed? No.
• Database migration needed? No.
• Exact steps: None.

Risks & Mitigations

• Risk: A broken resource may be less obvious because the skin remains visible.
  • Mitigation: Keep logging every load error and preserve fatal handling for
    explicit or indeterminate main-frame failures.

Contributor Responsibility

AI-assisted development is allowed. The submitter remains responsible for the submitted work.

• I have reviewed and understand all changes in this PR and take responsibility for their correctness, security, behavior, licensing, and provenance, including any AI-assisted or AI-generated work.