Artifact Signing: identical certificate structure to a publisher that passes SmartScreen, but our downloads are still withheld — is this purely download volume, or something on our account?

I want to ask a narrower question than the other threads on this, because I have a control that I think rules out most of the usual answers.

Our situation. We sign Windows binaries through Artifact Signing (account centerconsulting, East US). Signatures validate cleanly. Downloading our installer in Edge on a clean Windows 11 machine reliably produces "devthrottle-setup-win-x64.exe isn't commonly downloaded", and the file is withheld as Unconfirmed <n>.crdownload until the user finds the full downloads list and clicks Keep. Every release does this.

The control. On the same clean machine, in the same browser session, minutes apart, I fetched the current Python 3.14.7 installer. It came through clean in 10 seconds. Comparing the two certificates:

The certificate-policies extensions are byte-identical. So whatever is different, it is not the shape of the certificate.

What else I eliminated, each measured rather than assumed:

• Not the file changing each release. A publisher I also work with ships several updates a week over the same URL and is never warned about.
• Not the intermediate CA. Python is on EOC CA 04 too, the same CA created 2026-03-26 that several threads here blame.
• Not the host. The identical bytes served from github.com were withheld exactly as they were from our Azure blob (same SHA-256, verified).

The only remaining difference I can see is that our signing identity is young — first signed release 2026-07-05 — with low download volume.

My questions:

1. Is that the whole explanation, or is there anything visible on your side about our signing account that would differ from an established publisher's? I would rather know now than keep waiting on something that is not going to change.
2. Is there any way for a publisher to see the reputation state of their signing identity? At the moment the only instrument I have is downloading our own installer on a clean VM once a week and writing down whether it was withheld.
3. Older certificates on my machine — including Python's own from April 2025 — carry the CA/Browser Forum code-signing policy 2.23.140.1.4.1, while everything issued from the new CAs carries anyPolicy. Is that change intentional, and does it have any bearing on reputation?

Possibly related, possibly not: winget cannot launch either of our signed installers at all — it logs Starting: and the process is never created, while a third-party package installs fine on the same machine seconds later. I have filed that separately as microsoft/winget-cli#6506. I mention it only because "an unrecognised binary" is the one property our two failing installers share, and if the launch path consults reputation the two may have the same cause.

Happy to supply the signing account details, subscription id, full logs or a reproduction privately.