The problem with metrics is that they are just a proxy for something, so that trying to improve some metric can have unintended consequences. This is known as Goodhart's law:
When a measure becomes a target, it ceases to be a good measure.
The classic velocity measure in a process framework like Scrum is the story points delivered per sprint. A story point indicates estimated required effort, which is related to but distinct from estimated time. A scrum team is expected to increase velocity over time because they get better at estimating the effort and better at delivering value. But if the story points were used not merely as a description of the team's work but as a metric to be maximized, the estimate would become useless: the team would be incentivized to inflate their estimates or to make features more complicated than they are.
Kanban has a more sensible productivity metric: lead time, the time from inception of an idea to its delivery. It is expected that a team will reduce lead time over time as impediments and sources of variability are identified and eliminated. This metric is very good because it is difficult to game: improvements to the metric mean that value is typically delivered earlier, and that is good. It might be tempting to game this metric by splitting up work items into smaller chunks that can be delivered more quickly, but that again is good because value gets delivered more quickly (and more consistently!). Anderson suggests using the mean lead time and a spectral analysis (histogram) of lead times, I would suggest the median lead time as an easier to interpret metric.
The Kanban book has a whole chapter that discusses metrics, for example also Throughput (similar to Scrum velocity), number of Blocked Work Items (indicates the presence of impediments), Flow efficiency (ratio of lead time to the time the issue was actively worked on), Initial quality (escaped bugs per feature), and some others.
The metrics you suggest may or may not be helpful, but note that some approaches only make sense if you are aiming for Continuous Deployment. E.g. deployment frequency is an absolutely useless metric once you reach the threshold that deployments are easy, painless, quick, and ordinary. Since you don't do Continuous Deployment but have scheduled deliveries to customers, this metric would be largely meaningless.
Your stability metrics may or may not be useful depending on how you organize development. If you use an approach like trunk-based development then you want to minimize the time during which your software is in a broken state, because that would be an impediment to the whole team. In contrast, if you use a pull request based workflow where the merge of some feature into the mainline is performed by a continuous integration server, your mainline will never be broken by construction. Instead of tracking time spent on fixing builds, the Initial Quality or Flow Efficiency metrics from the Kanban book might be more helpful.
Measuring your release process might be useful, but since deliveries are rare compared to ordinary development it would seem unlikely that changing this process could lead to a noticeable velocity improvement.
One metric that is absolutely worth considering is time to feedback from your continuous integration and automated test system. In my experience, shortening this feedback time has compounding productivity improvements across the org. Easy ways to reduce feedback time is to have these checks fail fast, to prioritize cheap but risky checks, to parallelize building and testing, and to defer high-fidelity but slow checks like expensive simulations to scheduled “nightly” builds (but also make it possible to run them on demand). It doesn't really matter whether the feedback is red or green as long as actionable feedback is quickly available so that any problems can be fixed.
