Split jspod into:

- lib/start.js — exports start(options) returning a handle
  { url, port, host, root, ready, exit, stop }. Pod-startup logic,
  no process.exit, no banner, no signal handlers.
- lib/index.js — barrel export ({ start, formatUrl }).
- index.js — thin CLI shell. argv parsing, banner, install subcommand,
  SIGINT/SIGTERM handlers that call handle.stop() then process.exit.
  Behaviour identical to pre-refactor CLI.

package.json gets main + exports map pointing at lib/index.js, so
`import { start } from 'jspod'` works for host programs (e.g.
solid-desktop) that want to embed jspod in-process instead of
spawning the CLI as a child.

Smoke-tested both surfaces:
- CLI: node index.js --port 5455 --no-bootstrap → ready, served GET /,
  SIGINT → clean SIGTERM to JSS → exit 0.
- API: start({ port, root, open:false, bootstrap:false }) → ready
  resolves true, fetch returns 200, stop() returns {code:0,signal:null}
  and is idempotent.
- Bare-specifier import via `file:` install → imports 'jspod' and gets
  { start, formatUrl } as expected.

Adds `start({ inProcess: true })`: maps the same options to
javascript-solid-server's createServer() and listens in the current
process instead of spawning the `jss` binary. Lets jspod embed in
single-process runtimes (nodejs-mobile, Electron, tests) where forking
a CLI isn't possible, while still returning the same handle shape
(url/port/host/root/ready/exit/stop, plus the Fastify instance).

Post-readiness logic (seedPodFiles + bootstrap + open) is factored into
a shared afterReady() used by both paths, so the in-process pod gets the
same jspod onboarding pages.

Note: bootstrap still installs apps via git clone+push, which needs git
+ child-process spawning — unavailable in git-less runtimes (Android).
There the 'error' handler fires harmlessly and the embedder seeds apps
itself; a git-less install is a follow-up. Refs #58.