web: app lifecycle status + machine-readable data attributes on the Apps screen

[cliffhall]

Summary

Expose the app renderer lifecycle machine-readably so automated drivers can waitForSelector instead of sleeping:

• AppRendererStatus (loading | ready | error) + an onAppStatusChange callback on AppRenderer.
• AppsScreen surfaces it as data-testid="apps-form" with data-app-status and data-app-error attributes, plus data-testid="open-app" on the Open App button and data-testid="apps-stage" on the stage.
• Resource-read failures (via the bridge factory's onResourceError) render an error panel (data-testid="apps-error") instead of a silent blank frame.

Why

The programmatic-review path (deep-link auto-open, CI drivers) needs a deterministic way to detect "widget rendered" vs "widget failed, and why".

Reference implementation (PR #1510)

Re-implement informed by these changes at 33fac3f:

• clients/web/src/components/elements/AppRenderer/AppRenderer.tsx — AppRendererStatus, onAppStatusChange, status transitions
• clients/web/src/components/screens/AppsScreen/AppsScreen.tsx — appStatus/appError state, handleAppError(), AppErrorPanel, data attributes
• clients/web/src/components/screens/AppsScreen/AppsScreen.test.tsx — status/attribute tests (+273)

Depends on

• CSP enforcement + resource-error surfacing in the bridge factory (provides onResourceError; same files)

Wave 2 lane — sequential with the other AppRenderer/AppsScreen issues. Prerequisite for the deep-link openApp/autoOpen issue.

Notes

• Document the data-testid/data-* contract in clients/web/README.md (docs rule) — drivers depend on it staying stable.
• Coverage gate ≥90 on all four dimensions.

Part of the PR #1510 decomposition (see tracking issue).