Investigate missing navigation through PF 4336 underground entrances

User reports PF 4336 navigation fails to pass a narrow entrance into an underground corridor and supplied screenshot /tmp/pi-clipboard-ea89648f-51ce-4681-bc65-9ae438724abc.png. Investigate actual decoded meshes, measure aperture/collision dimensions, reproduce the missing route, and identify a supported remedy rather than guessing radius/profile changes. Use host dotnet and read-only /mnt/games/PRK-NEW/client assets. Do not launch client graphical verification; user handles that. Current branch feature/rebuild-world-navmesh-baking is clean at 132a78e8c (one unpushed visualizer commit). No commits, push, deployment or production navmesh/asset writes authorized for this investigation. Hypotheses to separate: outdoor radius/voxel erosion, headroom/ledge filtering, incorrect collision geometry or terrain occlusion, and post-bake reachability removing disconnected underground collision surfaces. Current outdoor profile cell size .32, radius .6, height 2; client WallSweep radius .4 discovered in code, but do not assume server/NPC dimensions or whole movement shape from that alone. Acceptance: identify relevant collision zones and rendered mesh/resource identities where available; establish measured doorway/floor/headroom geometry and reproducible path checks; compare controlled bakes with baseline and isolate the stage causing loss; recommend a safe change with tradeoffs and regression fixture requirements. Preserve unmeasured claims and remaining ambiguities. Measured investigation milestone All probes are external under /tmp/prk-4336-investigation; repository is unchanged. Host .NET 10 probe resolves current built client/shared libraries and opens /mnt/games/PRK-NEW/client read-only. Decoded 126132 triangles (100352 terrain) in 1953 geometry parts; exported snapshot and parsed all 559 statel placements / 21 unique visual meshes. - Main surface entrances: visual mesh 217932 at (272.82004,30.9,280.65698) and (262.41418,30.980345,436.66885). Stairs: 217951 (4 placements); straight corridors: 217924 (13); corner pieces: 224181 (9). Separate entrance01 mesh 224454 is at (243.39905,32.892117,119.9296), not assumed to be the supplied screenshot. Original visual mesh triangles decoded with the existing client StaticMeshDecoder and shared packed orientation, not an alternate parser. Collision parts at the first doorway include KD zones 126/146; relevant repeats also occur in 127/147. - First doorway cross sections around x275,z280.6, floor31.025: width1.4592 at floor+1m, 1.2774 at floor+1.9m, headroom3.52m. Walls taper inward. Adjacent terrain includes49.02-degree triangles. Existing client WallSweep radius is0.4; AlwaysRunning movement uses normalY>=0.5 (60deg), distinct from provisional nav radius0.6/slope45. - Actual headless BodyFrame.Run over the real OutdoorSurface/collision traverses from (267,32.5,280.6) through the doorway and stairs to (295.0046,23.095,280.6) in all three body variants, at2m/s and100Hz. This is measured existing client movement, not a newly relaxed traversal rule or graphical session. - Controlled local crop: baseline, unfiltered reachability, radius-only0.4 (still rounds to2voxels), reduced height1.8, zero region threshold, and cell-only0.16/0.08/0.04 all fail to cover the doorway. Radius0.4+cell0.16 restores doorway-to-lower-floor coverage but not outside connection; radius0.4+cell0.08+slope60 restores the actual outside-to-underground route. Removing slope60 or reverting cell0.16 breaks the outside connection. Zero-radius control can connect but is not a proposed fix. Final verified outcomes - Full baseline (radius0.6/cell0.32/slope45) took8.179s and misses the doorway and lower network targets after reachability. Full raw/unfiltered baseline DOES contain the connected lower corridor floors but still cannot enter from outside. Thus closed entrance connectivity causes reachability to discard the otherwise valid underground component; filtering is an amplifying consequence, not a substitute fix. - Full radius0.4/cell0.08/slope45 took107.829s: interior doorway coverage returns but first outside connection still fails. Full radius0.4/cell0.08/slope60 took111.911s: both entrances and all13 consecutive legs through the two lower levels pass. The actual AlwaysRunning client BodyFrame also traversed all14 waypoints continuously, including the four stair placements, without jumps or movement-rule changes. - Apparent long-route failure was isolated to the existing default48-polygon corridor buffer, not mesh disconnection: DT_SUCCESS|DT_BUFFER_TOO_SMALL (0x40000010). Budget96,256 and512 all succeed. Full fine route has29 straight points; mixed-resolution route has23. Do not confuse corridor polygon capacity with returned straight waypoint count. No out-of-nodes evidence was observed. - Fresh mixed-resolution proof uses agent radius0.4/slope60 globally, cell0.32 default, and cell0.08 only for64-unit entrance tiles(4,4) and(4,6). Tile bounds are X256..320/Z256..320 and X256..320/Z384..448. Coarse bake6.646s + two fresh fine bakes2.666s + global reachability/query0.056s = about9.37s. These are single-host Debug-library measurements, not production performance guarantees. Uniform fine bake was about112s. Diagnostic tile selection is intentionally external, not a hardcoded production PF exception. - Independent controls: refining only first entrance opens first but not second; refining only second opens second but not first; refining both opens both and the complete network; also refining the next lower-ramp tile is unnecessary. Both coarse and fine tiles use the same .4m radius,2m headroom,.8m climb and60deg slope; only resolution varies. Global reachability is applied AFTER assembling replacement tiles. Mixed tile sizes are not used: all are64 world units, with per-tile cell sizes already supported by the existing codec. - Saved mixed-two-entrances.dat, reloaded via NavigationTileSet.Read/CreateMesh, and rechecked all13 legs plus the complete outside-to-outside path. Budget96 succeeds with23 points across mixed-resolution seams; budget48 still returns buffer-too-small. No file-format change was needed for the prototype. Recommended implementation, not yet performed 1. Calibrate a named pedestrian bake profile against the existing movement footprint/slope rules (measured here: radius0.4 and60deg), retaining2m headroom rather than dropping ceilings or weakening collision. Preserve separate requirements for larger agents; this investigation does not establish one body profile for every NPC. 2. Support deliberate finer-resolution regions/tiles around constrained geometry, using shared tile baking and one global reachability pass. Do not hardcode PF4336 or particular mesh IDs as gameplay exceptions, and do not indiscriminately refine the entire playfield. Production selection policy and generic seam/budget regressions remain implementation work; the two-tile proof is not a completed adaptive refinement feature. 3. Handle path-buffer exhaustion explicitly with bounded retry up to the existing512 limit, rather than returning partial paths or assuming96 is universally enough. Add long-corridor and failed-route regressions. 4. Preserve a synthetic tapered-door + sloped-approach fixture and a read-only4336 route case covering both entrances/underground levels. No off-mesh teleport/link or collision bypass is needed. Completion/limits Investigation and remedy prototype are complete. Repository remains clean at132a78e8c; no tracked code/config/assets changed, no graphical client launched, no commit/push/deployment or production writes. Full implementation was not requested/performed. Evidence and temporary harness are under /tmp/prk-4336-investigation (census.log, statels.json, visuals.log, geometry.bin, measure.log, bake*.log, movement-network.log, mixed-fresh.log, routes-final.log and generated .dat files). The exact screenshot camera pose was not supplied; both identified surface entrances in the actual underground network were measured and exercised.