Guard clear_log() against missing status windows

[kendonB]

Description

This change makes clear_log() safer when clearing the Caster/Natlink status window.

It keeps the status window title in one local variable inside clear_log(), and it only calls FindWindowEx / SetWindowText when the expected parent window and RICHEDIT child control are actually present.

Related Issue

None.

Motivation and Context

This change is required because clear_log() currently assumes that the Natlink in-process status window always exists and always contains the expected RICHEDIT control.

In the current code, when Natlink is enabled in-process, clear_log():

• looks up "Messages from Python Macros" or "Messages from Natlink"
• immediately passes the result into FindWindowEx
• immediately passes the result of that into SetWindowText

That is fragile.

Example 1:

• Natlink is enabled in-process.
• Neither "Messages from Python Macros" nor "Messages from Natlink" is currently open.
• get_window_by_title(...) returns 0.
• clear_log() still proceeds with the Win32 calls instead of bailing out safely.

Example 2:

• The parent status window exists.
• The expected RICHEDIT child control does not exist.
• clear_log() still attempts to write to that missing control.

This patch fixes that by guarding both lookups before calling SetWindowText.

How Has This Been Tested

I have not functionally tested this in a Natlink in-process Windows environment.

I verified the following locally in the project .venv:

• Installed Dragonfly into .venv from ../dragonfly
• .venv/bin/python -m py_compile castervoice/lib/utilities.py
• .venv/bin/pylint -E castervoice/lib/utilities.py
• .venv/bin/python tests/testrunner.py

I also confirmed that the diff is limited to clear_log() in castervoice/lib/utilities.py.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue or bug)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Renamed existing command phrases (we discourage this without a strong rationale).

Checklist

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• I have checked that my code does not duplicate functionality elsewhere in Caster.
• My code implements all the features I wish to merge in this pull request.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests pass.

Maintainer/Reviewer Checklist

• Basic functionality has been tested and works as claimed.
• New documentation is clear and complete.
• Code is clear and readable.