GeezerVison

Why

Node.js publishes TracingChannel events (start, end, asyncStart, asyncEnd, error) around units of work, and so can any library or app. devframe had no way to list those channels or show what they trace. This is PR 1 of 3 from plan 009 (#426): the core primitive and its wire contract. PR 2 adds the inspect tab, PR 3 traces devframe's own RPC and shared-state writes.

What

• ctx.tracing on every node context (scoped contexts included): register, list, record, stop, records, clear, onRecord. register() returns Node's TracingChannel, so a producer declares and traces with one call.
• Known channels come from Node's built-ins (module.require, net.server.listen), register() calls, a new tracing.channels field on DevframeDefinition and on initHub / buildHub options, and ad-hoc record() names.
• Subscription is on demand, so the app pays no tracing cost until something records. Lifecycle events sharing one context object fold into one DevframeTraceRecord. A ring buffer keeps 500 records per channel.
• A serializer that never throws turns contexts holding sockets, requests, errors or cycles into JSON-shaped values.
• Core owns the wire: shared state devframe:tracing:channels, streaming channel devframe:tracing (one stream per recording channel, id published as streamId), RPC actions devframe:tracing:record|stop|clear. Names live in DEVFRAME_EVENTS and the events reference.
• DF0081 reports once where tracingChannel is missing; every method is a no-op there and register() returns a pass-through stand-in.
• Docs: new guide page, terms, events, node-api and hub-api references, error page.

One deviation from the plan: each recording gets a fresh stream id instead of reusing the channel name, because streaming.start({ id }) with an id that is still retained silently replaces the record. The plan doc gets this note in #426.

Created with the help of an agent.