fix: fall back to len(children) on malformed numchildren - #124

Closes #100

What

numchildren="abc" (or an overflowing value) made encoding/xml fail the whole response, because xProp.NumChildren is a strict int and rawLocked treats any parse error as fatal — a cosmetic engine quirk became a hard command failure. #98 reintroduced the attribute as a strict int; before #35 it was unknown to the decoder and ignored.

xProp now decodes numchildren leniently: a malformed or out-of-range value falls back to 0, and summarize's existing max(p.NumChildren, len(p.Children)) reports the received page size.

A type-level UnmarshalXMLAttr alone is not sufficient — it makes the struct's int fields opaque to the decoder — so xProp also implements UnmarshalXML, binding the remaining fields through a shadow struct. Nested property decoding is unchanged.

Tests

New cases in dbgp_test.go cover malformed ("abc"), negative (-5) and overflowing (99999999999999999999999) values: each parses without error and renders the received page size.

$ go test -race -count=1 -run 'TestUnmarshal|TestSummarize|TestDecode|TestReadPacket|TestQuoteArg' -v .
--- PASS: TestUnmarshalMalformedNumChildren (0.00s)
    --- PASS: .../malformed_numchildren
    --- PASS: .../negative_numchildren
    --- PASS: .../overflowing_numchildren
ok  github.com/crazy-goat/xdbg

Note on the full suite

TestToolsCallListenBadInit fails in this environment, but it fails identically on a pristine main checkout (verified with git stash — same subtests, same "no engine connected within 10s" error). It looks network/timing-dependent in WSL, not related to this change. CI on GitHub's runners is the authoritative gate.