Fix pline recursion loop when descending/ascending stairs

[Critlist]

Summary

• Fixes pline recursion loop while getting down the stairs #5 — infinite pru() → newsym() → pline() → pru() recursion that could crash the game with a stack overflow when taking stairs.
• Root cause: pru()'s "track last displayed @" tracking (a modern addition for redraw sync on modern terminals) has no notion of level identity, so after dodown()/doup() it holds the previous level's last position. pru() then calls newsym() on that foreign coordinate, which is frequently unconnected rock (typ==0) — hitting newsym()'s original-1982 pline("Bad newsym...") diagnostic. pline() can re-enter pru(), and since the tracking state was only updated after the newsym() call, the re-entrant call sees the same stale state and repeats forever.
• Two changes, both documented per docs/CODING_STANDARDS.md:
  • dodown()/doup() now call a new clearpru() right after moving the player onto the new level, so stale cross-level coordinates are never handed to newsym().
  • pru() now updates its tracking state before calling newsym() instead of after, so even a re-entrant call can no longer repeat the same call — makes the recursion structurally impossible regardless of cause.
• All original 1982 logic (including the "Bad newsym" diagnostic itself) is preserved untouched; only the modern addition's ordering/scope changed.

Test plan

• Full project build (cmake --build build) succeeds cleanly.
• Standalone repro harness (not checked in) built against both the pre-fix and post-fix hack.pri.c, reproducing the exact reported call sequence (pru at old position → level-data corrupted the way an unconnected new-level tile would be → pru at new position with flags.dscr set):
  • Old code: reliably SIGSEGVs after ~7000 recursive frames.
  • Fixed code: returns cleanly (exit 0).
• Manual playtest of repeated stair traversal in a real terminal session (recommend before merge, given this touches the render path).

🤖 Generated with Claude Code