Don't apply enclosing struct captures when a branch fails

[hdimer]

Fixes #216.

strct.Parse flushed the entire deferred-capture queue when its expression failed (ctx.Apply()), applying captures that belong to enclosing structs. When a lookahead disjunction later discards that branch, those captures have already been written, e.g. the Bad field in the repro ends up true.

Each struct now snapshots its start offset into the queue and applies only its own captures, on both the success and failure paths, leaving enclosing structs' captures for those structs to apply. Removed the now-unused Apply().

One behaviour change worth flagging: because an inner struct no longer flushes its enclosing structs' pending captures, the global order of setField calls across nested structs shifts. Field order within a struct is unchanged, so this is only observable through a Capture()/UnmarshalText() implementation with side effects.

Test: TestIssue216, the reporter's minimal repro. It fails on the unfixed parser with Bad: true and passes with the fix.

Used AI assistance on this; I reviewed and tested it.

[Pastalikek65]

Reviewed and tested locally against master: both new tests pass (TestStructCapturesInBadBranch — Bad is now correctly false instead of leaking true, and B: 4 — and TestNestedStructCaptureNoPanic), and the full go test ./... suite plus go vet are clean.

The approach is sound: scoping Apply to the struct\x27s own queue offset (ApplyFrom) is the minimal way to stop discarded lookahead branches from flushing enclosing structs\x27 deferred captures, and the queue truncation (p.apply[:start]) keeps the "apply exactly once" invariant. The offset-snapshot also guards the nested-struct edge case correctly.

Two small notes (non-blocking):

• ctx.Apply() callers were removed entirely — worth a quick grep in follow-ups that nothing else relied on the full-queue flush semantics.
• The out == nil (optional struct) path still leaves deferred entries in the queue; safe today because the top-level struct ultimately flushes from offset 0, but a comment noting that invariant would help future maintainers.

Otherwise this looks correct and ready to merge. Fixes #216 as far as I can verify.

[hdimer]

Thanks for the review.

On the first note: grepped, nothing else relied on the full flush. The only other place the queue moves is Accept, which appends an accepted branch's entries onto the parent, so they land at or after the in-progress struct's offset and that struct still applies them.

On the second: added a line there, but narrower than "nothing was deferred". A (@Ident 'x')+ that starts matching and then bails does defer a capture, it just dies with the discarded branch. The queue is back at applyStart either way, which is the part that matters, so that's what the comment says.

Separately, I dropped TestNestedStructCaptureNoPanic. Put the old context.go/nodes.go back and ran it: it passes against the unfixed parser, so it was never guarding #216. TestPosInjection and five other existing tests already exercise ApplyFrom at a non-zero offset, one of them deeper than that test did. Renamed the remaining one TestIssue216 and moved its types inside the function to match the rest of the file.