one file permission does not cause failure

[umadevis1]

FileWriteCoordinator.java: commitRemediationWrites now only records a rollback entry for a file after its write succeeds, instead of before attempting it. A file whose write itself fails is already in its original state and needs no rollback — so the rollback path no longer retries writing to the same permission-denied file, which is what previously escalated into a batch-aborting RollbackRemediationException. That specific remediation is now skipped (SOURCE_WRITE_FAILED) and every other remediation — for other files, other issues — proceeds normally. The whole batch no longer aborts.
RemediationProcessorTest.java: added a regression test (readOnlyFileWriteFailureIsSkippedAndOtherRemediationsStillApply) that makes one file read-only, runs two remediations (one targeting it, one targeting a normal file), and asserts the read-only one is skipped on its own while the other still applies.

Note: if a multi-file remediation successfully writes file A and then fails writing file B (permission denied), it still needs to roll back A's already-written change. If that rollback of A also fails (e.g., A independently became read-only too), we will still hit the batch-aborting RollbackRemediationException — because at that point a file has genuinely been left modified and the code can't safely undo it, so halting is arguably still the right call rather than silently continuing over an inconsistent source tree.