parser: report the depth cap at a token index, like every other error

[VeaaC]

A parser reports a failure position RELATIVE to the range it was given, and for the token parser that position is a token index -- the resolver maps it back to file:line:col on the way out. too_deep() stored in.front().byte_offset instead, so a byte count landed in the slot the resolver reads as a token index.

Both shapes ran off the end of the file: 60 nested messages in a 121-line file reported 122:1, and an option value with 51 nested '[' reported 3:1 for a bracket on line 2. The rejection itself was always correct; only its position was wrong.

The fix is 0, not a computed index: every caller checks the depth BEFORE consuming anything, so the offending token is its range's first, and the sequential combinators lift the offset as it propagates. That makes the input parameter unnecessary.

The tests assert the rendered diagnostic, since the position is the whole point. The first pins no line number -- it cannot see the cap and should not encode it -- and instead requires two files of DIFFERENT depth to report the same line, which is what a byte offset or a mis-lifted index breaks, plus that the line is inside the file and opens a message. The second pins column 62 exactly: "option x = " is 11 characters, so the 51st bracket -- the first one over the cap of 50 -- sits there.