Add `xmd syntax` for discoverable component documentation

[taras]

Motivation

Agents and people need an effect-free way to discover the complete syntax
available to an executable.md run. A consumer must not need prior knowledge of
the language's structural constructs in order to ask what it can write.

This is also the prerequisite vocabulary source for xmd prompt (#260): prompt
generation consumes the same structural descriptions that the CLI exposes,
rather than maintaining a second handwritten catalog.

Command

xmd syntax
xmd syntax --json
xmd syntax --include ./components --include ./more-components

• xmd syntax writes human-readable Markdown by default.
• xmd syntax --json writes the same information as deterministic structured
  JSON for external tools and agents.
• The command accepts the ordered, repeatable --include configuration used by
  xmd run. Explicit includes replace the defaults; without one it uses
  ["components", "."].
• Discovery describes the run host profile under the contextual cwd.
• The command performs inspection only. It does not expand a component body,
  execute eval or shell blocks, import a repository TypeScript module, launch an
  agent, mint execution or invocation authority, or create a journal.

Catalog categories

The result always contains these categories in this order:

1. Built-in structural syntax — the constructs canonical core recognizes
   before component resolution, such as <If>, <Each>, <Output> and
   <Content>.
2. Built-in components — the selected registered defaults in the run host
   profile, including core, Agent, testing and web components. Components the
   host declares to an execution, such as <Session>, are described from plain
   profile declarations without instantiating their authority-bearing factory.
3. User-provided components — the selected repository Markdown and
   TypeScript components found through the configured includes.

A name appears only as the implementation execution would select. A repository
component that overrides an ordinary built-in default therefore appears once,
under user-provided components, with the repository origin. Structural syntax
remains structural because a repository or registration cannot claim it.

Component discovery

Core enumerates candidate names from the effective run-profile declarations and
from repository paths that invert the existing dotted-name mapping:

• Name.md and Name.ts describe Name;
• Name/index.md and Name/index.ts describe Name;
• nested paths describe dotted names, so Ns/Name.md and
  Ns/Name/index.md describe Ns.Name.

Only paths that describe a name the component grammar accepts are candidates.
Candidate names are de-duplicated, then each is passed through the same
selectComponent() decision execution uses. The existing include order,
.md/.ts candidate order, reserved/default tiers, and repository override
precedence therefore remain authoritative.

A missing include contributes no names, as it does during execution. An include
root that exists but cannot be inspected fails the request rather than making a
partial catalog look complete. Each configured include root is resolved as the
directory the caller named; a symbolic-link root is refused.

Architecture amendment — selection-relevant symlinks. Traversal never follows
a symbolic link to a directory. It classifies a reported link only when the
link's complete logical path could participate in component selection: the path
is itself one of the candidate file spellings, or every path segment is a valid
component-name segment and could therefore be an ancestor of one. A relevant
link to a file is selected through its ordinary repository path; a relevant link
to a directory, to nothing, or to an unclassifiable target fails the whole
include. The diagnostic names the configured include and logical entry, not its
resolved host target.

A link behind a lower-case, dotted, hidden, or otherwise invalid logical prefix
is ignored. No valid component name can make probeComponentPath() probe
through that prefix, so ignoring the link cannot hide an implementation
execution could select. This replaces blanket refusal of every directory link:
with the default ["components", "."], blanket refusal made bare
xmd syntax fail in ordinary package repositories solely because
node_modules contains directory links.

Entries within each category are ordered by component name in Unicode code-point
order. Props, captures and syntax forms retain their declaration order.

Component documentation

Markdown components may declare these optional string metadata fields directly
in frontmatter:

---
description: Creates a temporary directory and expands its body inside it.
as: The absolute path of the temporary directory.
context: Commands and file operations in the body use the temporary directory.

props:
 prefix:
 type: string
 description: Prefix for the generated directory name
---

The fields mean:

• description: what the component does.
• as: what as="name" binds.
• context: what is applied while expanding the component body.

They remain ordinary Markdown metadata. They are not reserved and have no
execution semantics. Inspection recognizes resolved string values under these
names; another value remains ordinary metadata and contributes no documentation
field.

Registered and execution-declared TypeScript components can declare the
equivalent fields directly with their structural registration metadata. The
existing props and returns schemas remain the machine-readable validated input
and result contracts; JSON Schema description continues to document
individual props.

Documentation is optional for repository-authored components so existing
components remain valid. Every first-party structural construct and component
exposed by the run host profile provides a description, plus as and
context whenever those explanations apply.

Inspection contract

Core provides one effect-free structural result. The CLI Markdown renderer, CLI
JSON renderer and xmd prompt consume this value directly; neither invokes nor
parses another one's output.

The JSON projection has this versioned shape, reusing the existing
ComponentOrigin, PropsSchema, and ReturnsSchema contracts:

interface SyntaxCatalog {
 readonly version: 1;
 readonly categories: readonly [
 { readonly kind: "structural"; readonly entries: readonly StructuralSyntaxEntry[] },
 { readonly kind: "built-in"; readonly entries: readonly CompleteComponentSyntaxEntry[] },
 {
 readonly kind: "user-provided";
 readonly entries: readonly (
 | CompleteComponentSyntaxEntry
 | OriginOnlyComponentSyntaxEntry
 )[];
 },
 ];
}

interface StructuralSyntaxEntry {
 readonly kind: "structural";
 readonly name: string;
 readonly origin: Extract<ComponentOrigin, { kind: "structural" }>;
 readonly syntax: readonly string[];
 readonly description: string;
 readonly as?: string;
 readonly context?: string;
}

interface CompleteComponentSyntaxEntry {
 readonly kind: "component";
 readonly name: string;
 readonly origin: Exclude<ComponentOrigin, { kind: "structural" }>;
 readonly sourceKind: "registered" | "markdown";
 readonly inspectability: "complete";
 readonly forms: readonly ("self-closing" | "paired")[];
 readonly props: PropsSchema;
 readonly captures: readonly string[];
 readonly returnMode: "text" | "value";
 readonly returns: ReturnsSchema;
 readonly description?: string;
 readonly as?: string;
 readonly context?: string;
}

interface OriginOnlyComponentSyntaxEntry {
 readonly kind: "component";
 readonly name: string;
 readonly origin: Extract<ComponentOrigin, { kind: "repository" }>;
 readonly sourceKind: "typescript";
 readonly inspectability: "origin-only";
}

Every structural entry contains its name and structural origin, one or more
exact authored syntax forms, a description, and as or context prose when
those concepts apply.

Every fully inspectable component entry contains:

• name, category, selected origin and source kind;
• inspectability: "complete";
• accepted invocation forms (self-closing, paired, or both), in that
  canonical order;
• the canonical draft-07 props schema;
• captured prop names, separately from the schema that deliberately excludes
  them;
• returnMode: "text" | "value" and the effective returns schema ({ type: "string" } in text mode);
• optional description, as, and context.

The return mode stays explicit because a text component and a value component
declaring returns: { type: string } have the same schema and different
invocation contracts. Captures stay explicit because they are caller-visible
props that intentionally do not cross the JSON props boundary.

Repository TypeScript files are available but not safely inspectable in full:
their schemas and documentation live on module exports, and loading the module
would execute top-level code. They therefore appear with name, category,
repository origin, source kind and inspectability: "origin-only"; props,
captures, returns, forms and prose fields are absent. A future static manifest
can enrich them without weakening this command's no-import guarantee.

Repository Markdown is parsed without expanding its body. A component whose
prose fields are absent still appears with every structural field inspection can
safely provide.

Markdown output

The default output renders the three categories as separate top-level sections.
It is useful both as reference documentation and as agent prompt material.
Each structural construct shows its authored forms and purpose. Each fully
inspectable component shows invocation forms, purpose, props, captures, as
meaning, body context, return mode and origin when available. An origin-only
TypeScript component is identified as such and never presented as accepting no
props.

For example:

## Built-in components

### `<TempDir>`

Creates a temporary directory and expands its body inside it.

#### Props

| Prop | Type | Required | Description |
| --- | --- | --- | --- |
| `prefix` | string | no | Prefix for the generated directory name |

**`as`:** The absolute path of the temporary directory.

**Body context:** Commands and file operations in the body use the temporary
directory.

Acceptance criteria

• xmd syntax emits Markdown and xmd syntax --json emits the corresponding
  version-1 structured representation.
• Both outputs and xmd prompt are produced from the same internal inspection
  result.
• The result contains built-in structural syntax, selected built-in components,
  and selected user-provided components as separate ordered categories.
• Candidate enumeration and final selection agree with ordinary execution's
  includes, name mapping and resolution precedence.
• Traversal never follows a directory link. Candidate-relevant directory and
  dangling links fail the whole request; links behind a logical prefix component
  resolution cannot probe through are ignored.
• Bare xmd syntax remains usable with its default includes in an ordinary
  package repository whose node_modules contains directory links.
• Repeated --include values preserve caller order and replace the defaults.
• Markdown frontmatter description, as, and context string values appear
  in both output forms; non-string values remain ordinary metadata and are not
  documentation.
• Registered and execution-declared component documentation appears through the
  same fields without minting execution authority.
• Props and returns retain their canonical draft-07 schemas; captures,
  invocation forms and text/value return mode remain explicit.
• Undocumented repository Markdown components remain discoverable.
• Repository TypeScript components appear as origin-only and are never imported.
• Inspection performs none of the component's effects and creates no journal.
• Every first-party structural construct and component in the run host profile
  has complete applicable prose documentation.
• Category and entry ordering is deterministic.
• JSON and Markdown never describe an opaque TypeScript component as though it
  accepted no props.

Evidence

Use Markdown tests as the primary end-to-end evidence:

• all three categories render in their fixed order;
• a Markdown component declares description, as, context, and described
  props;
• xmd syntax discovers it and renders those declarations;
• xmd syntax --json reports the equivalent structure;
• an undocumented Markdown component remains discoverable;
• a repository TypeScript module that throws at top level is listed origin-only
  and is not imported;
• a component body containing an observable effect is not expanded during
  discovery;
• repository Markdown/TypeScript and index paths map to dotted names;
• a candidate file link is selected; a candidate-relevant directory or dangling
  link fails; a link behind a lower-case or dotted prefix is ignored;
• bare xmd syntax succeeds in a representative package tree containing
  node_modules directory links;
• duplicate names and component-directory precedence match execution;
• repeated --include values replace the defaults in caller order;
• a repository component overriding a built-in appears once in the
  user-provided category;
• <Session> is present even though inspection creates no execution claimant;
• captures and self-closing/paired forms are visible; and
• Markdown and JSON preserve the same names, categories, origins and structural
  fields.

Add focused core tests for metadata extraction, catalog enumeration, deterministic
ordering, registration and execution-declaration metadata, origin-only
TypeScript inspection, structural descriptions, captures/forms, and the
structured result. Avoid one snapshot of the entire catalog; assert meaningful
entries and category boundaries so routine description edits do not rewrite
unrelated evidence.

Out of scope

• Implementing xmd prompt itself.
• Executing components to infer documentation.
• Importing repository TypeScript components during inspection.
• A static documentation manifest for repository TypeScript components.
• Requiring documentation from repository-authored components.
• A structured ontology for contextual APIs or bindings; context is concise
  prose in this slice.