[winlog]: winlog input should suppress repeated warnings for non-existent Windows event log channels after initial detection

### Integration Name

Custom Windows Event Logs [winlog]

### Dataset Name

winlog.winlog

### Integration Version

2.5.0

### Agent Version

9.3.2

### OS Version and Architecture

Windows *

### User Goal

When the winlog input (via the custom Windows event log integration) is configured to collect from a channel that does not exist on a given host, the Elastic Agent emits a warning at every poll interval for the lifetime of the agent process. This results in continuous log noise with no actionable signal after the first occurrence.

It can happen for examplke when Microsoft Defender was never run, the Defender eeventlog doesn't exist. If WinRM was never installed / configured htere is no `Microsoft-Windows-Windows Remote Management/Operational`

To Reproduce

Deploy the custom Windows event log integration via Fleet
Configure a channel that does not exist on a subset of target hosts (e.g. Microsoft-Windows-Windows Remote Management/Operational on hosts where the WinRM event manifest has not been registered)
Observe agent logs on affected hosts

### Existing Features

Configuration of custom Windows event logs

### What did you see?

Current behavior: The agent emits a warning at every poll cycle for the duration of the process:

error.message: The specified channel could not be found

### Anything else?

Expected behavior:

The warning should fire once at agent startup or policy application, then be suppressed for subsequent poll cycles until the agent restarts or the policy changes. Optionally, expose a configuration flag such as ignore_missing: true to suppress the warning entirely for environments where channel absence on a subset of hosts is expected and by design.

To get rid of these warnings, the only way is to use custom Fleet policies for each system which has specific Windows event logs or not.

In heterogeneous Windows fleets it is operationally normal for a given integration policy to target host classes where not all configured event channels exist on every host. The current behavior makes it impractical to use a single Fleet policy across mixed host classes without generating sustained warning noise, and provides no additional diagnostic value after the initial detection.
Workarounds such as creating separate Fleet policies per host class are disproportionate to the problem and increase policy management overhead significantly.