feedback1f WU: fence-block docs - correct provenance, mark air blocking [ASSUMED]

SIM.md Blocking: the 薄绿 S2 drag case was found while checking community report F4 (深巡 on a fenced
tile), not reported by players; the passage now says so, keeps the surrounding base lines untouched and
wraps to the file's width. The air-blocking reading (blockFly units on a fenced tile still block flyers)
is marked [ASSUMED: PRTS restricts the rule to 地面阻挡] in SIM.md, Battle._blockerFor and the test file;
the _blockerFor doc also states that the gate reads ground passability (on the stages the fenced tiles
are the only low tiles ground units cannot pass). No behaviour change.

docs/SIM.md

@@ -177,16 +177,18 @@ user playtest #5 item 4): an unblocked, blockable enemy is blocked by an ally (o
 block radius of the enemy's position — `constants.js BLOCK_RADIUS`: ground 0.7071 (compared as d² < 0.49999037, the
 tile's circumscribed circle), air 0.8944 (blockFly units against flyers), devices 0.4472 — while that blocker has free
 capacity for the enemy's `blockWeight` (data `blockCnt`). A unit standing on a tile ground units cannot pass — the
-fenced 围墙 / 围栏 tiles (`b`: low, deployable, flyers only) — blocks no ground enemy (PRTS 围墙 / 围栏 地形机制 "部署在
-其中的单位，若当前阻挡类型为'地面阻挡'则无法阻挡敌人"; `Battle._blockerFor`): nothing walks onto those tiles, but a push or
-pull leaves an enemy at the fence edge, 0.5 from the unit — it walks on (community report F4 after 0.1.0: 薄绿 S2 on a
-fenced tile held the dragged enemies there; test/sim/feedback1f-fence.test.js); air blocking (blockFly against flyers)
-stays; a unit on a fenced tile still attacks whatever stands on its range tiles. It is checked every tick for every
-unblocked enemy, moving or not: an enemy that overlaps an operator when its blocker dies / is withdrawn / is stunned,
-or when the operator's blocked enemy dies, is taken over at once; an enemy that finds no room walks on (pass-through).
-Several blockers in contact → the nearest [ASSUMED]. A head-on enemy therefore stops at contact, ~0.71 tile from the
-blocker's centre, on the tile in front of it (PRTS 作战机制: a blocked enemy's collider does not enter the blocker's
-tile; the official few hundredths of a tile of deceleration are not modelled), and **every blocker** — melee units (要塞 / 领主 / 哨戒铁卫
+fenced 围墙 / 围栏 tiles (`b`: low, deployable, flyers only; the only low tiles of that kind on the stages) — blocks no
+ground enemy (PRTS 围墙 / 围栏 地形机制 "部署在其中的单位，若当前阻挡类型为'地面阻挡'则无法阻挡敌人";
+`Battle._blockerFor`). Nothing walks onto those tiles, but a push or pull stops an enemy at the fence edge, 0.5 from the
+unit; it walks on from there (found while checking community report F4 after 0.1.0, 深巡 on a fenced tile: 薄绿 S2 held
+the enemies she dragged against the fence; test/sim/feedback1f-fence.test.js). Air blocking (blockFly against flyers)
+stays [ASSUMED: PRTS restricts the rule to 地面阻挡], and a unit on a fenced tile still attacks whatever stands on its
+range tiles. It is checked every tick for every unblocked enemy, moving or
+not: an enemy that overlaps an operator when its blocker dies / is withdrawn / is stunned, or when the operator's
+blocked enemy dies, is taken over at once; an enemy that finds no room walks on (pass-through). Several blockers in
+contact → the nearest [ASSUMED]. A head-on enemy therefore stops at contact, ~0.71 tile from the blocker's centre, on the
+tile in front of it (PRTS 作战机制: a blocked enemy's collider does not enter the blocker's tile; the official few
+hundredths of a tile of deceleration are not modelled), and **every blocker** — melee units (要塞 / 领主 / 哨戒铁卫
 included), summons (流形's melee copy) and a ranged operator standing on a melee tile alike — may always target the
 enemies it blocks, in range or not, whatever its facing, and targets them first ("可以选择且优先选择阻挡单位", PRTS 选择器;
 the user's rule after playtest #6, "阻挡了就一定要能打到": officially the collision pushes a blocked enemy to its blocker's