can I directly add a table to this ERP database safely, maintaining new additions with a trigger, or will there be some kind of garbage collection/maintenance routine generally found on databases that would make this unsafe to do?
Firstly, I agree with Dan, that it's usually best to be in communication with the Vendor on what they're ok with in regards to changes you can make. Some are more flexible than others and can proactively advise you on what to avoid. Typically the kind of issues you run into is from compatibility problems between the software and the changes you make, or the upgrade process the vendor follows. If you make an incompatible change, the vendor is likely going to find out when you call them for support one way or the other anyway.
Secondly, it's always best to be as least invasive as possible, even with the vendor's permission. There's no guarantee that the objects you create or the changes you make in the vendor database will always be left untouched by the vendor application and / or upgrade process - even if the vendor tells you it's ok.
So with that said, an ideal solution would be to have a process that copies the data you care about outside of the vendor database and into your own database. This secondary database will be decoupled from the vendor's database and theoretically the vendor shouldn't have access to it (e.g. during upgrades). Then you don't have to be as concerned about the changes you make in that secondary database.
There are a couple ways you could do this, in order from least invasive to most:
Write a separate application / script that is scheduled and does bulk loading of the data at specific intervals. The downside is the data won't be synchronized real-time, if that's a requirement.
Use a native SQL Server data synchronization feature to copy the data to a separate database. Some of the available features are: Replication, AlwaysOn Availability Groups, and SSIS. The pros are they can mostly be used for real-time data synchronization, and as a more out-of-the box solution have less code to maintain. They each have their own limitations and aren't always the easiest thing to setup though.
Triggers - You can use triggers to copy data into other databases too. But now this enters the realm of invasiveness of creating objects in the vendor database. There's no guarantee that your triggers will always exist.
Once the data is migrated to your own database, you'll have full control on how you maintain the historical data. There's even out-of-box solutions SQL Server offers for maintaining table history for you, including Temporal Tables or Change Data Capture.
