parse_lines: avoid O(n^2) string rebuild on line continuations

[choudhryfrompak]

Each continuation line was merged into the accumulated value with f"{last.value}\n{data}", which rebuilds and copies the entire accumulated string on every continuation line. For a value spread across N continuation lines that's O(N) work per line, O(N^2) total — confirmed locally: 50k lines ~1.6s, 100k lines ~7.7s, 200k lines ~32.6s, consistent with quadratic scaling. A single pathological ini file in the low tens of MB can cost tens of seconds to minutes of CPU.

Fix: accumulate continuation fragments in a list per in-progress entry and join once when the entry is finalized (a new value/section line starts, or parsing ends), instead of rebuilding the string on every line.

The original had a subtle falsy-value quirk (an empty/falsy accumulated value gets replaced by the next fragment rather than newline-joined, matching its if last.value: concat, else: replace check) that I wanted to preserve exactly rather than risk changing. Verified with a differential test (test_parse_lines_perf.py) that keeps the original algorithm as a test oracle and runs both implementations across 10 edge cases (empty values, falsy continuations interleaved with real ones, continuations right after a section header, error cases) asserting identical results — plus a scaling test confirming linear rather than quadratic growth.

Full existing suite (71 tests total) passes unchanged. mypy --strict and ruff both clean.

[RonnyPfannschmidt]

closing as ai slop - the chosen implementation is horrible and overcomplicated, the attack vector is ludicrously contrived

#78 does it properly