docs(adr): split read and write runtimes out of core

[dfa1]

Summary

Proposes splitting Encoding into separate read/write interfaces and moving the corresponding runtime into reader / writer, leaving core as the model-only module it was originally intended to be.

PR #27's 33 unwrapForSubParser audit-trail sites are a strong signal that core is hosting the read runtime, not just the data model. Cross-module byte hand-offs force public escape-hatch APIs (VortexHandle.slice, Registry.decodeAsSegment) that no architectural wrapper can really cure.

Why this ADR

• VortexHandle.slice returning a raw MemorySegment is a symptom; the disease is the module layout.
• The 33 unwrapForSubParser sites collapse as a side effect of co-locating the decoder runtime with the byte source.
• Today a read-only deployment pulls in the entire write surface (Zstd encoders, FSST builders, ALP encoders). The split unlocks a true read-only artifact.

What the ADR contains

• Root-cause analysis of the current core layout (5 concrete smells).
• Target module split (core → model only; reader → read runtime + decoders; writer → write runtime + encoders).
• Six-phase migration plan with effort estimates (~9 person-days plus CI fallout).
• Consequences (positive and negative) and risks-to-manage.
• Rejected alternatives (JPMS hide, move FlatSegmentDecoder alone, adopt Arrow codec SPI, status-quo + docs).

Status

This PR adds only the ADR. No code changes. The ADR is marked Status: Proposed.

Test plan

• Reviewer: confirm the smell described matches reviewer's reading of the code.
• Reviewer: argue with the phase split — should Phase 5 (Extension) come earlier? Should Phase 2 (per-encoding-family lift) be done in one shot or per-family?
• Reviewer: estimate honesty — is ~9 person-days realistic?
• Decide whether to merge as Proposed, escalate to Accepted, or close as Rejected.

🤖 Generated with Claude Code