How many different questions you have :). In order:
1) Judging by the fact that the existing requirement to send letters does not fit into the SQL code, subsequent extensions of events may also not fit. Therefore, it is obvious that the logic of events should not be in a sequel. The variant you have proposed is quite normal, especially if there are no stringent response time requirements to ping the Event label less often.
However, you can look at this question from the other side: WHO and WHY writes directly to the database, since you are thinking about how to track changes in the database? If your application is writing there, track changes right there. If a third-party application is written there, let it write again through your API, and you will track changes. Think about it.
2) Regarding the number of triggers in the database and on the table. Their number is limited only by the number of objects in the database. For the 2005 sequel, the size can be viewed here: http://www.sql-server-helper.com/sql-server-2005/maximum-capacity-specifications.aspx
The performance of triggers affect just as much as you have there logic crammed. In your case, this will be an additional insert.
3) Regarding the support of the current database scheme with a version control system (the question actually deserves a separate discussion). The common version is this: script your current schema, put it in the version control system. All subsequent changes to the scheme make an upgrade scripts and put there. Important:
a) scripts must be rerunable,
b) scripts must have version
For example:
Script1.0 - the basic version of the scheme
Script1.1 - added Event table
Script1.2 - added a new column to the Event table
And so on. Thus, having driven the scripts sequentially from the beginning to the specific version, you get the base with the scheme corresponding to this version. Versions of scripts it makes sense to synchronize with the version of the application.