Preserve pre-write failure detection for substring replacements

When oldText is a substring of newText, this branch strips every newText occurrence before checking for residual oldText, so a pre-write failure can be misreported as success if the file already contained newText (for example, replacing foo with foobar when the file already has foobar and no standalone foo). In that case hasNew is true and stillHasOld becomes false even though no replacement happened, which reintroduces the false-success behavior this recovery guard was added to prevent.

Useful? React with 👍 / 👎.

Fixed in 89d88c5. Instead of only stripping newText from the content (which erases pre-existing occurrences too), the recovery now uses before/after occurrence counting via contentBefore: editAddedNewText requires the newText count to increase, and oldTextDecreasedOrAbsent checks oldText count decreased. When contentBefore is available, recovery requires both conditions. This closes the false-success gap for pre-existing newText. Also added a dedicated test for this scenario.

Edge case: pre-existing newText in file before write

The replaceAll strip works correctly when the edit succeeded, but there is a subtle regression for a specific scenario: if the file already contained newText (as pre-existing content, before any edit took place) and the upstream tool then threw before writing (e.g. because oldText was not found as a standalone match), this new path will strip that pre-existing newText occurrence, leave no residual oldText, and incorrectly return success.

Before this fix in that scenario:

• content = "foobar" (pre-existing)
• content.includes("foo") → true → stillHasOld = true → rethrow ✓ (correct)

After this fix in that scenario:

• contentForOldCheck = "foobar".replaceAll("foobar", "") → ""
• stillHasOld = false → false success ✗

This requires oldText ⊂ newText, the file having newText pre-populated, and the upstream tool using context-aware matching that didn't treat the substring as a valid match. In practice the edit tool does simple String.includes matching, so this combination is rare — but it does erode the protection the original comment specifically called out: "avoids false success when upstream threw before writing but the file already contained newText."

One way to make the guard tighter would be to only apply the strip when hasNew is true (already guaranteed at this point) and to document the remaining limitation explicitly.

This is a comment left during a code review.
Path: src/agents/pi-tools.host-edit.ts
Line: 65-68

Comment:
**Edge case: pre-existing `newText` in file before write**

The `replaceAll` strip works correctly when the edit succeeded, but there is a subtle regression for a specific scenario: if the file already contained `newText` (as pre-existing content, before any edit took place) and the upstream tool then threw *before* writing (e.g. because `oldText` was not found as a standalone match), this new path will strip that pre-existing `newText` occurrence, leave no residual `oldText`, and incorrectly return success.

**Before this fix** in that scenario:
- `content = "foobar"` (pre-existing)
- `content.includes("foo")` → `true` → `stillHasOld = true` → rethrow ✓ (correct)

**After this fix** in that scenario:
- `contentForOldCheck = "foobar".replaceAll("foobar", "")` → `""`
- `stillHasOld = false` → false success ✗

This requires `oldText ⊂ newText`, the file having `newText` pre-populated, *and* the upstream tool using context-aware matching that didn't treat the substring as a valid match. In practice the edit tool does simple `String.includes` matching, so this combination is rare — but it does erode the protection the original comment specifically called out: *"avoids false success when upstream threw before writing but the file already contained newText."*

One way to make the guard tighter would be to only apply the strip when `hasNew` is true (already guaranteed at this point) and to document the remaining limitation explicitly.

How can I resolve this? If you propose a fix, please make it concise.

Also fixed by the same commit 89d88c5. The exact scenario you describe (pre-existing newText, pre-write failure, oldText is substring of newText) is now handled: when contentBefore is available, recovery requires editAddedNewText (newText count must increase), so if the file was unchanged or only had pre-existing newText, the count stays the same and we correctly rethrow. The existing test "rethrows when oldText is substring of newText and file already had newText (pre-write failure)" covers this case. Also reverted the unrelated CSS changes from this PR.

Drop strict newText-count increase requirement in recovery

The recovery gate now requires newText occurrences to increase (editAddedNewText) before returning success, which causes false failures when a successful replacement does not raise that count. A common case is replacing a larger string that already contains newText (for example oldText="foofoobar" to newText="foobar"): after a real write, oldText is gone and newText is present, but the before/after newText counts can be equal, so this branch rethrows the original error instead of recovering from the post-write failure.

Useful? React with 👍 / 👎.