The standard library of a language is not usually treated as an explicit dependency, so you might choose to ignore it here.
However, attempts to quantify software engineering such as the instability metric you mention are problematic or even questionable. They are great for providing a definition in an academic paper, they are great for disagreeing with in a follow up paper, but they are often not a good model of reality, and therefore have no meaningful impact for practitioners.
For example, that instability metric can be criticized because it does not consider how large the dependency is (e.g. a single utility function versus a framework) or how tightly coupled the dependencies are. Without further context it is also not apparent what should be counted as one dependency: a library, namespace, class, or perhaps every single function? This will also depend a lot on the context for which you are using this metric. Perhaps a paper that introduces the metric discusses some of these points.
So basically: you have to consider for yourself how and for which purpose you are using this metric, and which data basis you want to use for calculating it. As it is not a commonly used metric by software engineering practitioners, there is no consensus regarding its use.
Edit: It appears that instability metric was introduced by Robert C. Martin. He presents them in his “Design Principles and Design Patterns” article (2000, Link via Wayback Machine) which refers to an earlier article “Stability“ (1997, Link via Wayback Machine). He describes stability as “Thus stability has nothing direclty [sic] to do with frequency of change. […] Stability is related to the amount of work required to make a change.” In “Stability” he mentions an
#include statement in C++ as an example of a dependency.