Fix chevron over-count, plane-lock diagonal frame connectivity, true one-way travel, iris shield independence

Chevron placement: the "protruding elbow" heuristic marked every
convex corner of a smooth ring as a chevron, which for a true
octagon/circle is *every* corner - producing 8 chevrons instead of a
deliberate subset. Replaced with a fixed, configurable count
(gate.chevron-count, default 7) evenly spaced along the ring's actual
geometric walk order.

Frame flood-fill leaking into unrelated structures: the diagonal
("stepped ring") connectivity fix from two commits ago used a full 3D
26-neighbor search, which let the flood leak sideways through the
ring's thickness into any other nearby structure sharing a frame
material (e.g. gilded blackstone used decoratively on a backdrop
wall), putting chevrons on it. The scan now bootstraps with a small
orthogonal-only flood to find the ring's plane first, then only
allows diagonal connectivity within that plane - never through depth.

One-way travel, properly this time: RuntimeGate gained an `outgoing`
flag, set true only on the gate that was actually dialed. The
teleport listener now only matches outgoing gates, so the destination
shows the event horizon but isn't walkable - stepping into it does
nothing, and only the dialing side can send a player anywhere.

Iris shield: it's a physical barrier independent of the wormhole, not
tied to "connected" state. Closed always means iris-shield-material
(default changed from IRON_BLOCK to BEDROCK per feedback), whether or
not the gate is even dialed right now. Only when the shield is open
does the idle/connected distinction (air vs event horizon) apply.
applyIrisMaterial() centralizes this so link, restart re-scan,
open/close, and the shield toggle all agree.

README.md

@@ -29,14 +29,11 @@ is the ring's "thickness" and only looks for the interior within that plane, so
 doesn't try to flood-fill out through the open air in front of and behind the gate.
 
 Chevrons aren't a separate material you place. When the gate is linked, the plugin
-flood-fills the ring, walks it in geometric order, and picks out the blocks that stick
-further outward than their immediate ring-neighbours - the "elbow" points of the
-shape, which is where a real Stargate's chevrons sit (an 11-wide octagonal ring like
-the reference design naturally produces 7 of them: the top apex, the four shoulder
-elbows, and the two side bumps). Those blocks swap to `gate.chevron-lit-material`
-(default glowstone) while dialing/open, and revert to whatever they looked like at
-rest when the gate closes - so a chevron can rest as plain obsidian and blend
-invisibly into the frame until it lights up.
+flood-fills the ring, walks it in geometric order, and picks `gate.chevron-count`
+(default 7) blocks evenly spaced around the ring's actual perimeter. Those blocks
+swap to `gate.chevron-lit-material` (default glowstone) while dialing/open, and
+revert to whatever they looked like at rest when the gate closes - so a chevron can
+rest as plain obsidian and blend invisibly into the frame until it lights up.
 
 1. Build the ring.
 2. Optionally place a button directly below where you'll put the sign - this becomes
@@ -61,20 +58,22 @@ material, unsealed interior, too far from the sign, etc.
 - **Right-click** the sign: cycles the destination shown on line 3 among the other
   gates on the same network.
 - **Left-click** the sign: dials the shown destination - chevrons light in sequence,
-  then the interior switches from `gate.iris-idle-material` (default air - an idle gate
-  is just an empty ring you can see straight through) to either the event horizon
-  (`gate.iris-open-material`, default water) or, if the iris shield is closed, to
-  `gate.iris-shield-material` (default iron block) instead, blocking travel even
-  though the gate is actively connected. It auto-closes after `dialing.open-seconds`,
-  switching back to the idle material either way.
-- Walking into the event horizon teleports you to the connected gate, arriving just
-  clear of its iris (never inside it - that would immediately teleport you right back)
-  and still facing whatever direction you were already walking, so entering forward
-  always means exiting forward.
-- **Right-click a button placed directly below the sign** toggles the iris shield.
-  Closing it never needs anything extra. If the gate has a pin set (`/sg pin <code>`),
-  opening a closed shield prompts you to type the code in chat within
-  `gate.pin-timeout-seconds` before it'll open.
+  then the interior becomes the event horizon (`gate.iris-open-material`, default
+  water) and travel opens up. It auto-closes after `dialing.open-seconds`.
+- Travel is **one-way**: only the gate you dialed *from* can send you anywhere.
+  Walking into its event horizon teleports you to the destination, arriving just
+  clear of its iris (never inside it) and still facing whatever direction you were
+  already walking, so entering forward always means exiting forward. The
+  destination's horizon is visible but not walkable - stepping into it does nothing,
+  same as a real Stargate only running one direction at a time.
+- The **iris shield** is a separate, physical thing from the wormhole connection.
+  **Right-click a button placed directly below the sign** to toggle it. Closed means
+  closed - `gate.iris-shield-material` (default bedrock), solid, blocking everything -
+  whether or not the gate is even connected right now. With the shield open, the
+  interior just reflects the connection state: `gate.iris-idle-material` (default air)
+  if idle, or the event horizon if actively dialed. Closing needs nothing extra;
+  if the gate has a pin set (`/sg pin <code>`), opening a closed shield prompts you
+  to type the code in chat within `gate.pin-timeout-seconds` before it'll open.
 
 ## Multi-world