Type checking a large Nat literal overflows the host stack without identifying the literal

Error: the machine stack overflowed (a deep recursion, or a literal too large to expand)

The source contains a single Nat literal and no recursive function.

On my environment (Bend 2.0.5, Bun 1.3.3, macOS 27.0 build 26A428, Apple M4 Pro, arm64):
- 5314n succeeds and prints 5314n.
- 5315n fails with the error above.
I reproduced both cases with bend main.bend and with bend main.bend -o main. The successful native executable also prints 5314n.

These are observed thresholds in this environment, not a documented language limit.

Cause investigated at commit e6676b0:
The parser already expands Nat literals iteratively into Succ constructors (bend2/bend.ts:2248-2250). Calling book_load and book_valid directly shows that loading succeeds and the RangeError occurs in book_valid, with this repeating stack:

RangeError: Maximum call stack size exceeded.
    at term_check (bend2/bend.ts:3480:21)
    at tele_check (bend2/bend.ts:1111:19)
    at term_check (bend2/bend.ts:3497:26)
    at tele_check (bend2/bend.ts:1111:19)
    ...

The CLI catches RangeError in bend2/main.ts:469-474 and replaces it with the generic message above. That message identifies neither the literal nor its source location. In a larger program, it is difficult to distinguish this from recursion in user code.

Expected:
- Avoid exhausting the host stack while checking the expanded literal, or reject unsupported depth with a clear diagnostic.
- Identify the offending literal and its source location when possible.
- If an intentional depth limit is introduced, document it and report it explicitly; 5314 should not be treated as a universal cap.

import Base

def main() -> Nat:
  5315n