Add --browser panes: opt-in pane-aware data browser, augmented by local panes #69

Supersedes #68 (which folded panes into the default folder browser via a node_modules override — replaced by the cleaner opt-in design below).

Idea

Add a third selectable data browser alongside data-browser.js (json) and data-browser-folder.js (folder): a pane-aware browser, chosen with the existing switch as --browser panes. The two existing browsers stay byte-for-byte unchanged, so it's fully opt-in with zero regression.

Crucially, the shipped browser is a shell — the actual panes live on the pod and are loaded at render time, so adding a pane is "drop a file on your pod," never "fork the shipped file."

Upstream surface (small + stable)

1. New file data-browser-panes.js — sibling browser. It reuses the folder/JSON rendering and adds pane resolution: read the #dataisland resource, match the primary subject's @type, and render a pane (collapsible Source underneath); containers and unknown types fall back exactly like the folder browser.
2. Widen the existing --browser switch to accept panes:
   • index.js — allow panes in the validation (currently json | folder).
   • lib/start.js — add panes to the browserFile map.

That's the whole upstream change. After it lands, all pane churn is local — upstream stays stable.

Local augmentation (your pod)

• data-browser-panes.js discovers and loads pod-local panes from /public/panes/ (e.g. bookmark.js, tracker.js).
• Each pane follows the losos pane contract (canHandle / render keyed on @type local name).
• Add a pane → drop a module under /public/panes/ → it renders. No fork, no republish.

First panes to ship as references: bookmark:Bookmark → card, wf:Tracker → task list.

Selecting it before publish

Until jspod publishes data-browser-panes.js, "select locally" means pointing the pod at a local copy of the shell (a transient --mashlib-module override). Once published, --browser panes resolves to the cdn copy by default and the override is removed.

Security note (for later, not this issue)

The shell loads pane JS from the pod being viewed — safe for your own pod, but rendering a foreign pod would execute that pod's JS. For cross-pod viewing, panes should come from a trusted registry keyed by @type, and data-declared views should be sandboxed/opt-in. Out of scope here; tracked separately when cross-pod rendering lands.

Done when

• data-browser-panes.js shell (folder/JSON + pane resolution + loads /public/panes/)
• --browser panes wired (index.js validation + start.js map)
• reference panes (bookmark, tracker) under /public/panes/
• renders verified via --browser panes (DOM-shim + live pod)