TL;DR; The first two metrics aren't bad, but the first is hindsight and the second organized information you already know. The third might line up sometimes, but will almost certainly get you in trouble.
The three important questions when trying to establish any metrics should be:
1) What exactly does this metric tell me?
2) What actions can I take based on this metric?
3) What behavior will this metric cause in my team?
While your first metric may be difficult to do, it's a great metric for looking back at your releases. Your second is also a good one, but it tells you what you already know - how many defects were found already in the changes. If you're interested in code risk, one thing that might be good is to see how many of those defects impact something that wasn't supposed to change. That could be an indicator of volatility problems in a release (though it's important to know that it's a red flag for it, not proof).
Your third metric may be problematic in that to get the value you want out of it, you're going to need to commit a lot of time. While 100 changes to a code base could cause a lot of errors and volatility, it could also be 100 steps toward improving the code. What would make me nervous is a lot of commits with comments like "fixed an omission from last build". However, that means reading through all of the commits to see what changes and if it looks good.
So, enough negative, what can you do to effectively judge code volatility and risky releases? It comes down to regression testing. The two metrics I'd use together to judge the risk of a release are:
1) how many changes were made to parts of the code that are not adequately covered by tests.
2) how frequently do your regression tests fail during development.
For the first metric, each change to code not under test is a coin flip. You have no idea what will happen with it. On the second, if developers commonly check in code that fails regression tests and have to fix it after, they aren't focusing on quality in their development practices.
Of course, this means a lot of testing and if you don't have a good suite of regression tests, you'll need to build one up. Definitely start with critical functions and areas that have caused problems in the past. This sounds like a lot of work, but trying to gauge risk off of metrics that sometimes correlate to volatility problems is gambling at best.