Do very short values make a peppered hash less secure? Given many very short (or low-entropy) values – like 6-digit numbers – that are stored as hashes using a fixed secret pepper, e.g.:

value  | pepper               | hash = SHA265(value + pepper)
-------+----------------------+-----------------------------------------------------------------
100001 | e03c920babf6325ac56d | 75e3283fe3dbc8e1f86ac5ea7ac5325896a6036d5d2d73f355dca41b9dab4a42
100002 | e03c920babf6325ac56d | 20b50e24dc8a984905de5850e67167928f937f171a2e6cb9998c0a8131a11dda
100003 | e03c920babf6325ac56d | f555173d08ebd020b45a655cee159c2684ad98cd4901dc85ec047b565d3a4a05


... and assuming that an attacker knows that the values are 6-digit numbers and that the hashes were computed that way.

Could the attacker retrieve the values (or even the pepper) from the hashes? Do the short values make the hash more vulnerable / less secure?
The assumption seems to be that the adversary wants to confirm a guess of $\mathtt{value}$ given $\mathtt{hash}=\operatorname{SHA-256}(\mathtt{value}\mathbin\|\mathtt{pepper})$, for unknown random secret $\mathtt{pepper}$. This is an ad-hoc PRF of $\mathtt{value}$ with symmetric key $\mathtt{pepper}$.

No, the small size/entropy in $\mathtt{value}$ is not an issue. Neither is having a million of millions of $\mathtt{value}$ (or/and of leaked $\mathtt{hash}$ ). Without a successful and complete guess of $\mathtt{pepper}$, as far as we know, the adversary can't learn anything about $\mathtt{value}$ from its $\mathtt{hash}$ (beyond two $\mathtt{value}$ being identical with practical certainty when their $\mathtt{hash}$ is, something that additional random public salt would fix, see Maarten Bodewes's answer). Main theoretical weakness is the relatively small size of $\mathtt{pepper}$ (here 80-bit), which should be 128-bit or more by modern standards. Of course, there's the issue of keeping $\mathtt{pepper}$ secret, and other implementation issues (but the classic timing side channel of memcmp does not matter).

The best known generic attack is essentially brute force. For each guess of $\mathtt{value}$, it enumerates $\mathtt{pepper}$, computes $\operatorname{SHA-256}(\mathtt{value}\mathbin\|\mathtt{pepper})$, and compares to the given $\mathtt{hash}$ (or the full list of theses). If there are several guesses of $\mathtt{value}$ with different likelihood, it pays to try the guesses from most to least likely. If $\mathtt{value}$ was long (so that $\mathtt{value}\mathbin\|\mathtt{pepper}$ exceeds the 64-byte block size of the SHA-256 internals), it would pay to cache the intermediate values that do not vary with each $\mathtt{pepper}$.

Note: we'd have better academic security assurance if we used HMAC-SHA-256 rather than this ad-hoc PRF. See M. Bellare: New Proofs for NMAC and HMAC: Security without Collision-Resistance, in Journal or Cryptology, 2015, originally in proceedings of Crypto 2006.