Add gated development App Attest bypass

[brow]

What changed?

Add a non-default development App Attest policy for iOS Simulator enrollment. The bypass accepts only the versioned development sentinels and is unavailable unless the gateway is explicitly compiled with dev-app-attest-bypass.

At runtime, enabling the bypass now fails closed unless both gateway listeners are loopback addresses and buzz-ios-sandbox is the only enabled profile. Default builds continue to use Apple's verifier. The gateway also records attempts that reach the APNs HTTP send seam.

Why?

The iOS Simulator cannot perform Apple App Attest, which otherwise makes local push enrollment structurally impossible. This provides a narrowly gated development path without adding bypass behavior to the production gateway build.

How is it tested?

Build and run.

Added tests:

• dev_app_attest
• config
• AppAttestPolicy compile-fail test

🤖 This PR was authored with an agent.

[brow]

@codex review

[brow]

@builderbot review

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.

[brow]

🤖 Superseded, closing. This work landed on the single feature branch push-ios-blockers-1-2 (draft #2744) per tomb's single-branch rule, in a strictly later form.

Where it went: three commits (6d7f118fa / 06841bcf9 / a8826c57b) plus the guard restore 737457569. The branch version is not a copy of this PR's b342d21d4, it is the reviewed evolution of it: the bypass is now reachable only through a capability token minted from validated config (AppAttestPolicy::from_config) rather than a bare AppAttestPolicy::Development, and config validation additionally requires both listeners loopback and enabled_profiles exactly {BuzzIosSandbox}, erroring rather than silently disabling on a non-canonical flag value. crates/buzz-push-gateway/src/dev_app_attest.rs is byte-identical between the two (sha256 aeb7ef02...), and the push_gateway_apns_send_attempts_total counter from this PR is present there as well.

Adversarial review happened against the branch version, not this one, and produced one landing condition that this PR does not carry: the development_bypass_stays_a_non_default_feature guard is the sole detection for flipping default = ["dev-app-attest-bypass"], which matters because Dockerfile.push-gateway:20 builds the release image with no --features. Mutating that line with the guard absent was caught by nothing (both arms 40/0, clippy clean); with the guard restored it fails by name in the plain cargo test -p buzz-push-gateway arm, and the resulting no-features binary was confirmed to contain the bypass symbols. Nothing is lost by closing this.