In your specific use case, Publishing is the Sitecore function that you are interested in. Therefore, I would create a Helix Module called Foundation.Publishing on the Foundation Level, and then add your Event Handler and associated patch configs there.
Generally speaking, customizations to Sitecore should be contained with the module that needs the customization.
For example, general enhancement modules, like Language Fallback, SEO, or multisite (to name a few) are kept at the Foundation level. Think of these as architectual elements that can exist and function completely on their own.
For more specific feature based modules that are options for various deployed websites and overall platform, these are to be kept at the Feature level.
And for specific project, website specific, non-shared modules of the website, these exist in the Project level.
For an event handler, such as item:saved, the question is, "Why do you need it? Which function of the business requirements require it?"
For example, say your business requirement is, "when an item gets saved, I want to update a specific Sitecore default field." Whatever module in the Foundation layer that you have that is handling Publishing or if this is for SEO, then code for the handler would go in one of those modules.
But, say for example you have a Feature module called CTA Card, the business requirment is "when I save a CTA Card item, I need to perform some action on the item:saved event". This would mean that the event handler you need is tied to (or has a dependency on) the CTA Card module. Therefore you would put the handler in the CTA Card module.
Put the event handler code in the module that most cloesly defines why you need it in the first place.
Keep Helix Dependency pattern in mind.