Elevate "cannot create an ingest target" from debug to warn

**Describe the enhancement:**

When filebeat (`docker.elastic.co/beats/filebeat:9.0.0`) comes across a file that is actually a symlink, it'll log an error, but only at debug level. I propose this error should be elevated to `warn` if not actually `error` because the issue apparently prevents filebeat from doing its job.

```
{"log.level":"debug","@timestamp":"2025-06-05T00:14:01.496Z","log.logger":"scanner","log.origin":{"function":"github.com/elastic/beats/v7/filebeat/input/filestream.(*fileScanner).GetFiles","file.name":"filestream/fswatch.go","file.line":388},"message":"cannot create an ingest target for file \"/var/log/containers/xxx-544b8dc447-fj2vc_default_xxx-cff9bc230b7655c87381224e7009f5efd19dc5d24a9fc4b6ea83a3ff1835757f.log\": file \"/var/log/containers/xxx-544b8dc447-fj2vc_default_xxx-cff9bc230b7655c87381224e7009f5efd19dc5d24a9fc4b6ea83a3ff1835757f.log\" is a symlink and they're disabled","service.name":"filebeat","ecs.version":"1.6.0"}
```

**Describe a specific use case for the enhancement or feature:**

This would just make it easier to figure out why filebeat isn't forwarding logs. If you don't run at debug level, you'd never know why it isn't working.

Start in filestream/fswatch.go at fileScanner.GetFiles and the logged "cannot create an ingest target" message. Trace the symlink-disabled path and inspect nearby logging conventions before deciding whether the message belongs at warn or error level. Done means users can see this failure without enabling debug logging.

Written by the indexing model from the issue text.