Refactor event emission to report payload parsing non match even with no RepoMatch

[chmouel]

Problem Description

The initial processing of incoming Git events involves payload parsing (parsePayload) before Pipelines-as-Code (PaC) attempts to match the event to a known Repository Custom Resource (CR) and its corresponding user namespace.

If an error occurs during this early payload parsing stage (for example, within functions like pkg/provider/github/parse_payload.go or similar files for other providers like Bitbucket, Gitea, or GitLab), the error is currently not emitted to the user's event stream if a corresponding Repository CR and target namespace have not yet been identified or matched.

The existing error handling flow confirms this limitation: if there was no match for the namespace, the error will be logged in the Pipelines-as-Code Controller's logs. Currently, logging messages are emitted to the Namespace Event stream only after a namespace has been successfully matched to a repository.

Consequently, if the incoming payload is malformed or invalid, preventing successful identification and matching, the user that has no access to the controller logs receives no feedback through Kubernetes events in their target namespace.

Proposal

The code should be refactored to ensure that critical parsing errors are emitted as events that are accessible to the user, potentially within the controller's namespace or a mechanism that defaults to logging/reporting the error via the Git provider interface, even if a full namespace match fails.

This refactoring should aim to decouple the emission of basic event errors (like payload format errors) from the successful completion of the repository-to-namespace matching process. If possible, a mechanism should be implemented (perhaps leveraging components in pkg/events/emit.go) to ensure that even preliminary errors generated before Repository CR matching are communicated back to the user or made visible in a designated monitoring channel, rather than being silenced solely in the controller logs.