A transient grid at describe time permanently removes that rock from the cell

[rebaserHEAD]

Branch: feat/worldgen-sensed-tier. Found by the describe/placer parity workflow on 2026-07-30 and adversarially verified. Small and narrowly scoped — see the window at the bottom before spending time on it.

CellDescribeSystem.Describe rejects a sample point when a grid overlaps its safety box:

if (HasCollisions(mapComp.MapId, safetyBounds.Translated(point)))
    continue;

No record is written, and Describe never runs again for that cell: it is reachable only through DrainPending (CellDescribeSystem.cs:245) and EnsureDescribed (:266), both guarded on SensedCellComponent, which is added at :287 and never removed anywhere in the tree. Chunk entities also outlive unload — WorldControllerSystem.cs:182-186 strips only LoadedChunkComponent — so "never again for that cell" is effectively "never again for the life of the map".

The stock placer caches no such thing. OnChunkUnloaded sets DoSpawns = true (DebrisFeaturePlacerSystem.cs:118), and once GC empties OwnedDebris the points ??= GeneratePointsInChunk(...) fallback at :196 mints a fresh point set.

So a transient obstruction gets baked into cell content permanently. A grid that happens to sit on a sample point when the cell is first described removes that rock for good, where the placer would have re-rolled the area on a later cold load.

What this is not

The verifier killed three larger framings, worth recording so they do not get re-derived:

• Not "the sensed belt is a subset of the placer's". The placer spawns inside its own loop, so each rock it places feeds the collision check of the next point in the same chunk. Describe spawns nothing and never sees sibling debris, so it keeps records at points the placer would have self-suppressed. Neither set contains the other.
• Not the double gate. Materialize re-running the check (DebrisMaterializeQueueSystem.cs:299-308) is the placer's own spawn-site gate kept where it always was, and it is strictly more forgiving — EnqueueCell resets BlockedAttempts = 0 on every cell load (:110), so a materialize-blocked record retries across load cycles where the placer's skip was final for that load.
• Not full recovery on the placer side either. DebrisFeaturePlacerSystem.cs:187-194 reuses OwnedDebris keys on any reload where the dict is non-empty, so a blocked point stays absent across those reloads too. Recovery needs a full GC drain and arrives as a new point set, not as that point returning.

Window

With describe_range at 3072 m against a loader radius in the low hundreds, an approaching ship normally describes a cell long before it can obstruct anything in it. The realistic triggers are FTL and spawn arrivals that appear inside an undescribed cell, and on-demand EnsureDescribed loads that outran the sweep.

Note while in here

++record.BlockedAttempts < MaxBlockedAttempts at DebrisMaterializeQueueSystem.cs:301 with MaxBlockedAttempts = 3 gives 3 attempts / 2 retries, not 3 retries. Cosmetic, but the name reads as the latter.