Of course you are now not getting any audit events anymore because there is no audit source called "share-site-access" unless you have also implemented a custom Java component that generates audit events with that source.
I believe there is some confusion / misunderstanding of some aspects of auditing that is at the heart of this, and it does not help that Alfresco reuses names for different elements.
- PathMap source: This is the path / name of audit entries as "recorded" in Java via the AuditComponentImpl - you cannot freely choose this and are fully dependent on what Java components actualyl record data. With Alfresco there are only two valid sources out of the box: /alfresco-api and /alfresco-access
- PathMap target: This is the path / name that relates to the Application to which you want to route audit entries for actual recording / storing, so this always begins with the /<key-of-your-application
- audit.filter.<name>.<setting>: Here, the name always relates to the name for the Java component that records audit entries via the AuditComponentImpl - so essentially the source of the PathMap, never the target
Confusion likely arises from the fact that Alfresco by default comes with both a source and a target called alfresco-access, and Alfresco also documents that the audit.filter can be used to restrict what the audit application alfresco-access records, when in fact, it restricts what the source alfresco-access provides even before PathMap is processed. The effect is the same, apart from the fact that other PathMap which use alfresco-access as the source to a custom target are also transparently affected by the filtering.
In your case, unless you develop custom Java components to record data entries separate from alfresco-access, you will have to use alfresco-access as the source for your custom application, and CANNOT configure a filter separately from alfresco-access.