Define stable ordered scene records, render roles, and tile admission

[zoeyrose]

Important

This issue is implemented in the fresh MIT-licensed Go server under the replacement program. Its gameplay and content-design decisions remain authoritative. C, CPython, classic packet, file-path, and enum details in the preserved specification are historical evidence only; do not copy, translate, or structurally port GPL implementation code.

Replacement implementation contract

Implement the greenfield Go scene projection/admission model directly. Game Protocol 1 owns transactional scene snapshots; the shared renderer owns bounded consumption. Do not implement a 49-slot compatibility representation.

The server remains authoritative, consumes versioned compiled content, and exposes bounded generated Game Protocol 1 messages. Pure rules may use a specifically approved typed CEL environment. Starlark is not part of this issue unless the separate residual-scripting decision explicitly approves it.

Required verification

• Preserve every observable rule, balance decision, disclosure boundary, and anti-exploit invariant from the specification below.
• Add deterministic Go unit/property tests and wrapper-managed scenario coverage at the appropriate integration boundary.
• Add bounded malformed-input and persistence-failure cases where this feature accepts content, network, or stored data.
• Add Go/Rust protocol conformance fixtures for every new cross-process field; the client must not reconstruct authoritative rules from prose.
• Demonstrate that implementation and tests contain no copied GPL source/test material and execute no runtime Python.

Preserved product/design specification and historical implementation notes

Parent and roadmap

• Parent tracker: Ordered world model: compile, simulate, stream, render, and edit stable scene records atrinik#156
• Roadmap: Roadmap: replace classic Atrinik with a fresh MIT Go and Rust stack atrinik#168
• Roadmap milestone: M2
• Prerequisites: Proposal: establish stable content identities and cross-reference validation content#19, Content tooling: establish grammar contracts and a lossless parity corpus content#17

Outcome

Introduce the transport-independent ordered scene model and centralized bounded admission rules while retaining current display and elevation storage.

Scope

• Inventory layer/sub-layer consumers and authored overrides; capture visual/gameplay fixtures for decorations, support surfaces, actors, effects, projectiles, and linked depths.
• Define stable scene-record identity, authored sequence, named finite render bands, support-surface references, and separate semantic gameplay indexes.
• Add centralized admission APIs and measured quotas for authored records, ground-item stacks, living entities, transients, total encoded records/bytes, and per-update work.
• Preserve item ownership on rejection/redirect, reserve authoritative living capacity, coalesce only cosmetic effects, and expose occupancy/rejection metrics.

Superseded path / cleanup target

Stop introducing new numeric draw-priority workarounds. This child does not yet delete MapSpace.layer[49] or sub_layer; it prepares named owners and migration evidence.

Acceptance criteria

• Three or more fixed records can be represented in authored order without consuming unique display slots.
• Below/at/above-limit admission tests cover every record class and preserve item/actor ownership.
• Scene identity is stable across map generation, multipart parts, and runtime objects without pointer or flattened-slot identity.
• A synthetic extreme pile remains bounded and produces actionable diagnostics.

Validation baseline

Before: one layer/sub-layer field simultaneously controls display uniqueness, gameplay lookup, support elevation, and delta identity.

After: one bounded scene model owns presentation order while explicit admission and semantic indexes protect gameplay state.

Run server model/admission tests, corpus scans, save/reload fixtures, capacity stress tests, and targeted GCC/Clang/MinGW builds.

This issue is a bounded child of atrinik/atrinik#156. The parent remains open until every sibling child is complete.