perf(daemon): drop the per-log-line String reallocation in the log task

[phil-opp]

Issue

The daemon's per-node file-logging task ran this for every log line of every spawned node (binaries/daemon/src/spawn/prepared.rs):

let formatted = content.lines().fold(String::default(), |mut output, line| {
    output.push_str(line);
    output
});

content is an owned String moved out of the LogLine and not used afterward. It holds a single logical line — read_capped_line stops at the first \n — so this fold does nothing but strip the trailing newline, yet it heap-allocates a brand-new String and copies the entire line byte-for-byte. On a node logging at high frequency that's an allocation + full copy per line, on the log hot path, for no benefit.

Fix

Introduce a small strip_trailing_newline(String) -> String helper that pops a trailing \n (and a preceding \r) from the already-owned buffer in place, and use it instead of the fold. No allocation, no copy.

For the single-line inputs the reader produces, the result is byte-for-byte identical to content.lines().next().

Validation

• Added strip_trailing_newline_matches_lines_for_single_line, which diffs the helper against the old .lines().fold(...) implementation across \n, \r\n, bare \r, empty, mid-line \r, trailing-spaces, and truncated-marker cases.
• cargo +1.97.1 fmt -p dora-daemon -- --check — clean.
• cargo +1.97.1 clippy -p dora-daemon -- -D warnings — clean.
• cargo +1.97.1 test -p dora-daemon strip_trailing — passes.

---

⚠️ This is a machine-generated pull request authored by Claude (Claude Code). A human should review before merging.

🤖 Generated with Claude Code

---

Generated by Claude Code

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[phil-opp]

🤖 Automated review by Claude Code — fully automated review, not vetted by a human.

No issues found.

I verified the optimization against the code. read_capped_line reads with read_until(b'\n', raw) (binaries/daemon/src/spawn/prepared.rs), so content is a single logical line holding at most one trailing \n (and possibly a preceding \r), with no embedded newlines. Under that invariant the old content.lines().fold(...) and the new strip_trailing_newline are byte-for-byte identical:

• The fold only concatenated lines and dropped terminators; with a single line it merely stripped the trailing \n/\r\n.
• A lone \r (truncated line) and no-newline input are preserved by both.
• Empty, "\n", and "\r\n" all collapse to "" in both.

content is moved out of LogLine at the use site and not read afterward, so consuming it in place is safe. The differential unit test (strip_trailing_newline_matches_lines_for_single_line) checks the helper against the old fold across representative cases, which is a meaningful guard rather than a tautology.

---

Generated by Claude Code