docs: add First Run page (you've installed it, now what)

Replaces the brief stub in core-concepts/content-negotiation with a
substantive position document covering JSS's conneg architecture:

- Position commitment: any app speaking JSON-LD works today; conneg
  surface is future-proofed against the W3C standards track
- Four design constraints (W3C-aligned + future-proofed, deployed-web
  compatible, deployed-semantic-web compatible, JSON-LD first)
- "Content negotiation is a negotiation" framing — the conneg handshake
  is by definition two-way; JSS implements its side correctly for
  clients that implement theirs
- Current behaviour table covering extensioned RDF, .acl/.meta,
  containers, extension-less resources, non-RDF
- A living-position flexibility statement
- Why these architectural choices (URI extension as web-reliable
  signal; octet-stream as spec-correct safe default; no JSS-local
  metadata layer pending LWS)
- Future-proofing posture (LWS-native adoption when REC lands)
- How it works (concrete code references)
- Direction (vague considerations-only; no specific implementation
  commitments)

Establishes the citable substrate-quality reference for JSS's conneg
behaviour, with deliberately hedged language for any unshipped
implementation choices.

…ation-position

docs(content-negotiation): replace stub with full position document

…o references

Adds the W3C Design Issues post 'Mapping http: and file: spaces' (TBL, 2015)
to the References section as background on the filesystem ↔ HTTP mapping
question that JSS's content-negotiation architecture engages with.

…erence

docs(content-negotiation): add TBL HTTPFilenameMapping reference

#18)

* docs(websocket-notifications): state position + lightly spec solid-0.1

Existing page was a thin tutorial. Two gaps closed:

- Position section: JSS picks solid-0.1 as the primary notifications
  surface. Performance is a non-negotiable design constraint;
  solid-0.1 is ~10x lighter than WebSocketChannel2023 on every axis
  (round-trips, frame size, multiplex, client code). Channel-based
  protocol may be added later as a compat layer, not a replacement.
- Light reference spec: frame types (greeting, sub/ack/err, pub,
  unsub), semantics (multiplex, ACL scope, ordering, no payload,
  lifecycle), implementation limits, reconnect contract.

Adds JS + websocat examples. Closes #17.

* docs(websocket-notifications): reference solid-spec api-websockets, mark JSS additions

solid-0.1 IS specced in solid/solid-spec/api-websockets.md. Earlier
draft mistakenly claimed otherwise. Restructure to:
- Link the spec as authoritative for sub/pub/protocol greeting
- Add the Sec-WebSocket-Protocol header convention
- Add container subscription (spec feature, was missing)
- Reframe ack/err/unsub as JSS-specific extensions, not part of solid-0.1
- Keep the position section (legacy-first for performance) as is

* docs: Sec-WebSocket-Protocol header is optional in practice

The header was a later spec addition. SolidOS, mashlib, and our
reference clients all omit it. JSS doesn't require it. The first-frame
'protocol solid-0.1' greeting is the practical version handshake.
Drop ['solid-0.1'] from both code examples.

Covers Phases 1+2+4+6 of JSS#464 — bare name / org/repo / URL / refs /
renames, bearer + NIP-98 auth, --pod targeting, --bundle (with the
JSON-LD shape + the solid-apps/bundles repo), how it works under the
hood, and a troubleshooting table.

Sidebar entry added under Features, next to git-integration.

Fixes #19

Mirrors the in-repo docs/mcp.md from
JavaScriptSolidServer/JavaScriptSolidServer#491. Lays out the thesis,
auth model, full tool reference, Claude Desktop wiring, and the
Charlie use case.

Slotted at sidebar_position: 15, after Git Integration and App Install
in the Features category.

… footguns) (#22)

Mirrors the in-repo docs/mcp.md update from JavaScriptSolidServer#497
and #498. Adds sections for the three new tools shipped in JSS 0.0.201
plus the Footguns section covering relative-vs-absolute WebID
resolution in write_acl agents.

New features/account-management.md documenting the self-service
user-rights trio plus passkeys, each with method, path, auth, request
body, response shape, and failure modes:

- PUT /idp/credentials      change password (#351)
- GET /idp/account/export   pod backup/export, tar.gz + manifest (#353)
- DELETE /idp/account       account deletion, optional purgeData (#352)
- GET/POST /idp/account/delete  browser delete flow
- POST /idp/passkey/*        WebAuthn register/login
- jss account delete <user>  operator CLI

Wired into the Features sidebar after Authentication, added to the
features overview table, and cross-linked from authentication.md.

Closes #23

Adds docs/features/charlie.md as the narrative/architectural complement
to the MCP doc. Covers the TBL 2017 / Inrupt 2024 lineage, the WAC-as-
language thesis, a verbatim agent-meets-WAC interaction trace, and a
starting SKILL.md template.

The MCP doc remains the technical reference (connection, tools, per-
client recipes, layout). Charlie doc is the pattern and demonstration.

Sidebars updated to place 'features/charlie' immediately after
'features/mcp' so the agent-integration docs read as a coherent series.

Closes #25

Adds the SolidMap demo video (33s, YouTube) as a new "Watch the loop
close" subsection at the end of "What it looks like in practice".
Complements the existing read/comprehend trace with a visual
write/render demonstration: Charlie generates JSON-LD into a pod
path; markmap app on the same pod renders the data live.

Together the text trace and the video cover both registers of the
Charlie pattern: read-and-reason, write-and-render.

Closes #27

New Features page covering the plugin system as of JSS v0.0.213:

- status table: appPaths shipped (#582/#585), plugin zero running,
  raw-body (#583) and getAgent (#584) proposed, loader designed
  (#206/#564)
- how-to: mounting an app with appPaths, the WAC-exemption rules,
  pod identity as the app's login (getWebIdFromRequestAsync + the
  browser /idp/credentials bridge), and the scoped raw-body pattern
  for wrapping node-style handlers
- case study: Tideholm as plugin zero (WebID -> player, dual-mode,
  runnable demo)
- roadmap: loader -> bundled-feature migration -> richer seams,
  with the never-load-from-pods security rule stated

Registered in the Features sidebar after MCP. Site builds clean.

Status table and identity section updated: the public accessor is
import { getAgent } from 'javascript-solid-server/auth.js' — the
internal-import caution is gone, the agent-identifier contract
(WebID or did:nostr DID, five credential schemes) is stated, code
samples use the public seam, and the roadmap moves getAgent from
proposed to shipped. Also fixes a token-TTL aside that pointed at
the wrong issue.

Lead with createServer({ plugins }) and the activate(api) contract;
appPaths/getAgent/raw-body move to 'the machinery underneath'. Status
table gains the loader and ws.route rows; bridge joins Tideholm as the
second reference plugin (the realtime one, with the WebSocket ticket
pattern); road-ahead reduces to CLI config block, #564 migration, and
consumer-demanded seams.

The loader page was written at v0.0.215 and called several shipped seams
'proposed' or 'road ahead'. Update to reality:

- Status table: api.mountApp (#590), api.serverInfo (#601/#605),
  api.reservePath (#602/#607), api.plugins (#610/#612) all shipped in
  0.0.217–0.0.218; the CLI config-file + --plugin flag shipped (#593/#595).
- activate(api) sample gains serverInfo() and api.plugins; the api-surface
  paragraph documents reservePath and mountApp.
- id derivation: generic <name>/plugin.js now derives from the parent dir
  (#596, 0.0.219), so distinct plugins get distinct ids with none set.
- Add the --plugin module@prefix CLI form.
- Rewrite the raw-body section to lead with api.mountApp (it shipped) —
  the manual pattern is now the under-the-hood note.
- Reference set: add the 33-plugin out-of-tree suite (dashboard, DAV
  family, the shims, S3, JMAP, …) alongside Tideholm & bridge.
- Road ahead: CLI + mountApp done; next are api.events (#603) and
  api.authorize (#604), then publishing the plugin suite as a package.

Docusaurus build passes.