This is probably not the correct forum for your questions as they are more about database design than the frontend. Even so, I am a little surprised to see that you have had no responses to date. As I see it, the main question here is whether or not triggers are good or bad, and opinions will be varied. But as they say "fools rush in where angels fear to tread" so I will try to give you something to chew over. Please note that this is my opinion based on my experience.
Triggers are a useful tool but are often abused by database developers who lack experience and therefore knowledge/ideas of other ways to do things. The very worst instances of trigger implementation are cases where a developer has used a trigger to replace foreign key functionality. I'm pleased that is nothing like what you are proposing here.
Personally, I avoid them, but that does not mean I think they are bad. The main reason I tend to avoid them when designing an application and its database, is that they are not very transparent - they are sort of tucked away and easy to miss when trying to understand what is going on with a database that you didn't design and develop yourself. In your case, if you are wanting to get rid of VB code or the snapshots, you could consider using a stored procedure to do the updating - use the AfterUpdate event on your controls/form to execute it.
Triggers can have performance issues when used on a table with very heavy transactional traffic so you need to bear this in mind. This is especially true if you are planning on using any sort of import function that might employ a bulk insert operation. They are also difficult to control and to incorporate in any testing regime - they at least make this a little more difficult.
So in answer to (a), your current use for the trigger functionality seems innocent enough, though I do have some reservations as to the necessity of maintaining a summary value on the database itself. I am not a normalisation freak, but I try to limit de-normalisation as much as possible and so it is natural for me to question it when I come across it. As a developer/designer I tend to think ahead to the people who come after me in terms of maintaining what I build. Given this approach, I tend to consider triggers an over-complication and try to find another approach which is both simple and easy to follow.
In terms of (b), I would say yes, the triggers will fire if there is a change to the data (Insert/Update/Delete), regardless of how that change is being made. However, I am reluctant to give you any sort of answer on (c) as it is out of my direct experience. Instinct suggests that they should fire if any sort of change to the data is taking place, but I can't be definitive about that. I hope someone else can advise in this respect. However, if practical experience shows that the triggers do not fire, there are other ways to deal with it eg a stored procedure executed on a regular basis by a SQL job would be one possible solution.
If you don't get much of a response here, I think you should perhaps do some research on the pros and cons of using triggers and get a feel for other peoples opinions/experience that way. Maybe post on one of the other forums here.
Best of luck.