Context-aware mailbox: stores [ctx msg] pairs.

This is a pure wrapper around mailbox that handles the [ctx msg] format.
It does NOT know about processes - context merging is the caller's responsibility.

Messages are stored as [ctx msg] pairs to enable context propagation
for distributed tracing through message chains and exit signals.

System lifecycle management.

Usage:
(require '[loom-otp.core :as otp])

;; Start the system first
(otp/start!)

;; Main API - loom-otp.process provides most things:
;; - spawn, spawn-link, spawn-opt - create processes
;; - self, send - current process and messaging
;; - exit - terminate processes
;; - link, unlink - bidirectional links
;; - monitor, demonitor - unidirectional monitors  
;; - receive!, selective-receive! - receive messages (functions)
;; - alive?, processes, process-info, register

;; For pattern-matching receive:
;; - loom-otp.process.match for receive!, selective-receive! macros

;; For virtual thread futures:
;; - loom-otp.vfuture for vfuture macro

;; Behaviors:
;; - loom-otp.gen-server for gen_server behavior
;; - loom-otp.supervisor for supervisor behavior
;; - loom-otp.timer for timers

;; Stop when done
(otp/stop!)

Generic server behavior implementation.

Provides a standard way to implement servers with synchronous calls,
asynchronous casts, and message handling.

Mailbox implementation for message passing.

A mailbox is an atom wrapping a persistent queue with watch-based
notification for efficient blocking receive.

Compatibility shim providing otplike.gen-server API backed by loom-otp.

Key differences handled:
- Returns [:ok pid] tuples instead of {:ok pid} maps
- Uses otplike-style process/! for messaging
- Integrates with loom-otp.otplike.process async/await

Compatibility shim for otplike.proc-util.

In otplike, execute-proc creates a process context using go blocks.
In loom-otp, we use virtual threads directly via vfuture.

Compatibility shim providing otplike.process API backed by loom-otp.

Key differences handled:
- `!` function for sending (vs loom-otp's `send`)
- `proc-fn`, `proc-defn` macros (vs loom-otp's plain functions)
- `async`/`await!`/`await!!` implemented via vfuture
- Tuple returns [:ok pid] vs map {:ok pid}
- `receive!!` variant (blocking) is same as receive! in virtual threads

This namespace does NOT modify loom-otp internals.

Compatibility shim providing otplike.supervisor API backed by loom-otp.

This wraps the gen-server-based supervisor implementation to return
[:ok pid] tuples instead of {:ok pid} maps.

Compatibility shim providing otplike.timer API backed by loom-otp.timer.

otplike.timer returns channels as timer references.
This shim wraps loom-otp.timer's Timer records to provide similar semantics.

Compatibility shim providing otplike.trace API backed by loom-otp.

Main process API.

This namespace provides the primary interface for working with processes:
- spawn, spawn-link, spawn-opt for creating processes
- self, send for current process and messaging
- exit for termination
- monitor, demonitor for unidirectional monitors
- receive!, selective-receive! for receiving messages (function-based)
- alive?, processes, process-info for introspection
- register for name registration

Pids are Thread objects directly.

For pattern-matching receive macros, see loom-otp.process.match.

Minimal core process primitives: current process, messaging, exit signal handling.

This namespace provides the foundation that other process.* namespaces build on.
Pids are Thread objects.

Process identity is determined by Thread -> process-map lookup in ConcurrentHashMap.
One process = one thread = one mailbox. No cross-thread context sharing.

Exit handling: exceptions, reasons, and exit API.

Bidirectional links between processes for fault propagation.
Pids are Thread objects.

Pattern-matching receive macros using core.match.

This namespace provides macros for receiving messages with pattern matching:
- receive! - FIFO receive with pattern matching
- selective-receive! - selective receive with pattern matching

For function-based receive without pattern matching, see loom-otp.process.receive.

Unidirectional monitors for observing process termination.
Pids are Thread objects.

Message receive functions.

This namespace provides function-based receive operations:
- receive! - FIFO receive, returns message or :timeout
- selective-receive! - predicate-based receive, scans mailbox

For pattern-matching macros, see loom-otp.process.match.

Process creation: spawn, spawn-link, spawn-opt.

Single-thread model: each process runs in one virtual thread.
Exit signals are handled by interrupting the thread directly.
Pids are Thread objects.

Process name registry.

Allows processes to be registered under symbolic names for
location-transparent messaging.

Uses ConcurrentHashMap for thread-safe operations.

Global state management for loom-otp.

Uses mount.lite for state lifecycle, enabling:
- Clean startup/shutdown
- Parallel test sessions with isolated state
- Proper cleanup on stop

Pids are Thread objects directly. ConcurrentHashMap provides
thread-safe access without contention.

Supervisor behavior for managing child processes.

Implements supervision trees with restart strategies.

Timer functions for delayed and periodic operations.

Timers are implemented as processes:
- One-shot timers: unlinked process that sleeps then executes
- Interval timers: linked process that loops, stopping when caller dies

All timer functions return a Timer record that can be passed to cancel.

Tracing infrastructure for debugging and monitoring.

Set a trace handler to receive events about process lifecycle
and message passing.

Core types: TRef, Async.

Pids are now Thread objects directly - no wrapper type needed.

Types defined here:
- TRef: Reference (for monitors, timers, etc.)
- Async: Asynchronous computation result

Virtual thread future - like clojure.core/future but always uses virtual threads.

Usage:
(let [f (vfuture (expensive-computation))]
  ;; do other work
  @f)  ; blocks until computation completes

Exceptions thrown in the body are re-thrown when dereferencing.
Dynamic bindings from the calling thread are preserved.