Fix: Harden malformed input

[gage-marshall]

Harden parsing against malformed and hostile PDFs

A PDF is untrusted input. This package reads sizes, counts, offsets and object
numbers straight out of the file and uses them to allocate slices, index them,
and seek, mostly without checking them first. A file of a few hundred bytes can
therefore panic the process, spin a core forever, or drive a multi-gigabyte
allocation.

The starting point was make([]xref, size) in readXrefStream, where /Size
is used unchecked. Auditing outward from there turned up the same missing-guard
pattern in 20 places across read.go, lex.go, page.go and text.go. Every
one below was reproduced against master before being fixed.

This continues work already in the history: d295ac1 "fix infinity loop",
1e65caa "avoid infinite loop on missing page", #11 "fix-out-of-memory", and
tries to close out the class rather than one more instance of it.

Why it matters

Three of these are worse than an ordinary panic, because a caller cannot defend
against them with recover:

	Effect
/Size in the mid range (e.g. 1e9)	Reaches the allocator instead of the length check, so it is a Go out-of-memory error: fatal, not recoverable
Cyclic /First in an outline	Recurses until the goroutine stack is exhausted: fatal error: stack overflow
Unterminated hex string	Infinite loop, pinning a core until the process is killed

The rest are panics, which matter because they escape APIs that look safe.
NewReader did not recover at all, so simply opening a file could take down
the caller. Page.Content has no error return and still panicked.

What's here

Cross-reference table (read.go)

Trigger	Before
/Size 4611686018427387904	makeslice: len out of range; ~1e9 -> OOM
/Size -1	panic in make
/Index [4000000000 1]	~128 GB growth loop on one entry of input
/Index [5 1] with /Size 0	index out of range [5] with length 5
4000000000 1 subsection header	same 128 GB growth, classic-table path
trailer /Size -1	slice bounds out of range [:-1]
/W [-1 2 1]	slice bounds out of range [:-1]
/W [2e9 2e9 2e9]	6 GB make([]byte, wtotal)

One of these deserves a specific note: growing a slice's capacity past an
index does not necessarily grow its length past it, so table[x] could still
be out of range after the grow loop. The classic-table path has the reslice that
handles this; the xref-stream path was missing it. That is the /Index [5 1] row.

The table is deliberately not bounded by the file length. That was my first
attempt and it is wrong: an xref stream is compressed, so a small file can
legitimately describe far more objects than it has bytes. TestCompressedXrefStreamManyObjects
is the counterexample that rules it out: 100,000 objects in under 8 KB, which a
length-derived bound rejects. Instead the preallocation is capped on its own
(the table still grows to whatever the file really contains) and object numbers
are bounded separately.

File structure (read.go)

The trailing-newline strip loop read buf[len(buf)-1] after emptying buf:

for len(buf) > 0 && buf[len(buf)-1] == '\n' || buf[len(buf)-1] == '\r' {

&& binds tighter than ||, so once the loop empties buf the third operand
still evaluates and indexes buf[-1]. A ~100-byte file ending in newlines
panics. The next line's bytes.TrimRight(buf, "\r\n\t ") already does this job
correctly, so the loop is simply deleted.

startxref and /Prev offsets are now range checked before reaching the lexer,
which reports a permanently unreadable stream by panicking. A negative
startxref also produced slice bounds out of range [:4101] with capacity 4096
inside reload.

NewReaderEncrypted now converts the lexer's panics into errors. The lexer
signals malformed input by panicking (buffer.errorf), which is fine
internally, but it meant every caller opening an untrusted file had to recover
for itself or crash.

Lexer (lex.go)

readByte returns a synthetic '\n' at end of input once allowEOF is set, and
readHexString treated that as whitespace to skip â�� so <AB with no closing >
looped forever. seekForward could leave buf.pos negative, which indexed out
of bounds on the next read rather than at the seek.

Content streams, CMaps, outlines (page.go, text.go)

Trigger	Before
Q with an empty graphics stack	index out of range [-1] out of Page.Content
268435456 beginbfchar	2.7e8 entries (~8.6 GB) from a 76-byte stream
5-byte codespace range	index out of range [4] with length 4 (cmap.space is [4])
empty bfrange destination ()	index out of range [-1]
odd-length bfchar replacement	index out of range [3] in utf16Decode
cyclic /Parent, /Kids, /Next	infinite loop
cyclic /First	fatal stack overflow

CMap entry counts were declared by the file and trusted. A count is now honoured
only if the operands to fill it were actually supplied, which bounds the work by
real input rather than by an arbitrary limit.

Interpret's own panics (mismatched begin/end, def without open dict) also
escaped readCmap into Page.Content. A malformed cmap now degrades to no cmap,
which is what a failed parse already did.

Two bugs found along the way

GetTextByColumn and GetTextByRow recovered into unnamed results:

func (p Page) GetTextByColumn() (Columns, error) {
    result := Columns{}
    var err error
    defer func() { if r := recover(); r != nil { err = ... } }()

The deferred function only reassigned its own locals, so a panic surfaced as
(nil, nil), caller sees no error and no data. Naming the results fixes it.
Reader.GetPlainText and Reader.GetStyledTexts never recovered at all, though
both call into resolution and Page.Content, so they could not honour their
error returns either.

Compatibility

No exported signature changes. Behaviour changes only for input that previously
crashed, hung, or silently returned nothing.

Two deliberately conservative choices, to avoid breaking files that work today:

• The Tm operand check in walkTextBlocks is a lower bound (< 6), not != 6.
  args is built from the whole stack, so a stream leaving extra operands behind
  keeps working exactly as before.
• resolve carries its recursion depth as a parameter rather than on Reader.
  A Reader only reads immutable state once opened, so several goroutines can
  read from one concurrently; a counter on the struct would have quietly
  introduced a data race. TestConcurrentReads pins this.

The limits are named constants at the top of read.go and page.go, each with a
comment explaining what it bounds and why, so they are easy to adjust if any turn
out to be too tight in practice.

Tests

There were no tests in the repository, so the CI job running go test ./... had
nothing to run. This adds malformed_test.go: 101 assertions across 17 tests,
go vet clean.

Every malformed case was individually reproduced against master before being
fixed. Reverting the source changes while keeping the tests fails as expected �
demonstrated for the panicking and hanging cases; the multi-gigabyte allocation
and fatal-stack-overflow cases were each reproduced on their own instead, since
running them unfixed takes the test process down with it. Each case runs under a
timeout, so a regression that reintroduces an infinite loop fails instead of
hanging CI.

The suite also pins what the bounds must not break:

• a well-formed PDF end to end (NewReader -> Page -> Fonts -> GetPlainText -> Content -> Outline)
• a PDF keeping its objects in an object stream indexed by a cross-reference stream
• a well-formed multi-entry ToUnicode CMap
• a table larger than the preallocation cap, to prove capping the preallocation does not cap the table
• a compressed xref stream describing 100,000 objects in under 8 KB

gofmt reports read.go, but only for pre-existing doc-comment style
(# Overview, ``-style quotes) that predates this branch. I left it alone
rather than mixing a whole-file reformat into these changes.

Reviewing

Five commits, one per file, so they can be reviewed or cherry-picked
independently.