Avoid logging expected report-lock contention

[IanHollow]

Summary

When another process is already handling a crash report, Crashpad correctly treats that report as busy. It also logs a File exists error for the expected lock conflict. That message can make a normal handoff look like a crash report failure and hide errors that need attention.

This change suppresses the message for the expected lock conflict. Other file errors still produce a log message.

Evidence

The existing code returns a busy result when opening a report lock fails because the lock already exists. Its logging helper prints an error before the code handles that expected result. The one location changed here keeps the busy result and only removes that premature log. A downstream Linux behavior test passed for pending and completed report contention and confirmed that a real permission error still logs.

Validation

A Linux behavior test covered two processes trying to use the same pending or completed report. It confirmed that the reports and locks stayed intact and that a real permission error still produced a diagnostic. The exact PR head also built with upstream CMake and Ninja. That build registers no CTest tests, so the separate behavior test is the direct check of this change.

OpenAI Codex (GPT-6) helped prepare and test this change. The contributor reviewed it.