refactor(walls): classify and migrate eligible wall families

[zoeyrose]

Parent: atrinik/classic#332

Outcome

Classify the existing wall corpus and migrate only proven-compatible families to the canonical topology/form/material/variation model in bounded, reviewable batches.

At atrinik/content@02f3092, 665 type-77 wall objects span full 48×47 blocks, ordinary directional pieces, tall/windows, fortified, palace, cave, animated/turnable, glowing, and other exceptional behaviors. Similar dimensions or colors alone do not make them interchangeable. This issue begins after the sand vertical slice and reusable generator establish safe migration mechanics.

Inventory and classification

Generate a deterministic report for every wall object and placement covering:

• stable archetype/face/animation identity and usage count;
• gameplay/property signature, blocking/visibility behavior, animation/turning, glow, and draw_double;
• image dimensions, alpha silhouette/anchor, topology/orientation, and candidate form class;
• candidate family/material/variant relationships and exact compatibility result;
• provenance, license, permitted consumers, and availability of reusable authored sources; and
• disposition: eligible-existing-variant, eligible-generated-recipe, fixed-intentional, exceptional-unsupported, unused-retained, or provenance-blocked, with a reason.

Do not classify by filename prefix or perceptual similarity alone. Archetype behavior, alpha/anchor geometry, and authored/provenance review are gates.

Migration policy

• Migrate one form/family class per reviewed pull request after a deterministic dry run lists every changed object, map placement, alias, generated face, fallback, and exclusion.
• Preserve stable legacy archetype/face identities as aliases or fixed fallbacks until an explicit tombstone policy proves no map, script, tool, save, or package consumer remains.
• Preserve intentional per-map fixed variation and exceptional behavior.
• Keep automatic variation opt-in; absence of a family/recipe remains the exact current singular face/animation path.
• Stop a batch when validation, visual comparison, provenance, or author intent is ambiguous; record the exclusion instead of guessing.

Acceptance criteria

• The inventory accounts for all type-77 wall definitions and all current map placements at the recorded content commit, with stable machine-readable and human-reviewable output.
• Every eligibility decision names the validated form/topology/material/variation compatibility evidence or the exact exclusion reason.
• The first post-sand batch covers one bounded geometry class and is idempotent, dry-run-first, visually reviewed, and independently reversible through retained legacy identities.
• No migration changes collision, movement/visibility blocking, animation, glow, layer, anchor, draw_double, construction semantics, scripts, lore, or unrelated map fields.
• Generated and existing-member families render deterministically alongside completely unconverted walls in the same scenes.
• Unused, exceptional, ambiguous, or provenance-blocked assets are reported but not deleted or silently normalized.
• Each batch passes content schema/map validation, deterministic generation/packaging, Classic reference rendering, affected two-client scenarios, and git diff --check with exact revisions recorded.
• The final report identifies which remaining families need new authored forms/materials, special runtime support, provenance work, or intentional permanent legacy treatment.

Non-goals

• Converting all 665 wall objects in one change or declaring migration complete by percentage alone.
• Treating recolors, same-size images, or shared filename prefixes as sufficient compatibility proof.
• Deleting unused or legacy assets as incidental cleanup.
• Porting provenance-blocked Classic pixels to the MIT renderer/editor.