Route ownership rules served by the server (Hotwire-style path configuration) instead of compiled into the app #149

Blocked-by: #144
Blocked-by: the first native-page card ruled under the four preconditions in docs/HYBRID-SHELL.md (Route ownership). No such card exists yet; replace this line with its number when one is ruled.

Context

The shell decides per Console route whether the WebView or a native screen renders it (lib/shell/route-owner.ts, DEFAULT_ROUTE_RULES). Today that table is compiled into the app, so moving a route to a native screen, or back to the web when a native screen misbehaves, needs a store release.

Hotwire Native solves the same problem with a path configuration: a JSON document fetched from the server at launch, cached on the device, and merged over a bundled default. It maps URL patterns to presentation rules. Its rules-as-data model is the reference here.

Ruling (maintainer, 2026-11-02)

d: not now, end state c (Recommended)

• Not now. Today there are zero native screens and zero route rules (DEFAULT_ROUTE_RULES and NATIVE_SCREENS are both empty), so there is no route to move and no pull for a delivery channel. This card waits for the first native-page card that the charter admits; such a card needs mobile usage and web performance readings.
• End state (c). The rules are a platform setting, delivered through the platform's anonymous runtime-config endpoint (GET /api/v1/runtime/config, the same path branding already takes), cached on the device, with the bundled table as the fallback.
• Rejected options:
  • (b), app metadata: a spec key the platform itself would never act on (ADR-0078). It would also let an author declare a native screen the shell does not ship.
  • (a), a static file: a second configuration channel beside the platform's existing one.
• Execution when unblocked:
  1. File the platform card first in objectstack-ai/objectstack: a mobile settings-namespace entry plus a runtime-config field, strictly validated and omitted when unset, in the same shape as branding.
  2. This card then becomes Blocked-by that card.
  3. The mobile side ships once a platform release containing it is reachable by the configured server.

Ask (when unblocked)

1. At launch, the shell fetches the route rules from the server's runtime config. It caches the last good copy, and falls back to the bundled DEFAULT_ROUTE_RULES when the fetch fails or the payload is invalid. A payload error is logged to Sentry once.
2. The payload is versioned and validated strictly. An unknown owner, a malformed pattern, or a screen name this build does not ship resolves to web, as resolveRoute already does.
3. Rules apply on the next launch, not mid-session, so a navigation never changes owner under the user.

Acceptance

• Unit tests cover fetch, cache, fallback, validation, and the build-lacks-screen fallback.
• docs/HYBRID-SHELL.md (Route ownership) documents the payload.