ci: add PR + push-to-main workflow (fmt/clippy/test/build) + ip-allowlist deny integration test

[luthermonson]

What

Adds the missing PR + push-to-main CI gate for the middleware modules. Until now the only automation was release.yml (tags / workflow_dispatch), so the 8 modules could land with no automated build, lint, or test. This closes that hole.

.github/workflows/ci.yml

Triggers on pull_request and push to main, with a concurrency group that cancels superseded runs. All runners are GitHub-hosted ubuntu-latest — mirroring release.yml, these pure-Rust modules must not contend with the self-hosted ephemerd fleet. Toolchains are pinned explicitly (the repo has no default rustup toolchain, and fmt needs nightly). Jobs:

• fmt — cargo +nightly fmt --all -- --check (nightly + rustfmt; the repo's rustfmt.toml uses unstable options).
• clippy — cargo clippy --workspace --all-targets -- -D warnings (stable).
• test — cargo test --workspace (stable). CARGO_NET_GIT_FETCH_WITH_CLI=true set workflow-wide so the git-dep ephpm-middleware ABI crate fetches.
• build — cargo build --workspace --release, proving every cdylib links before a release tag would catch it.

Integration coverage: ip-allowlist deny → 403

Deliverable 2 asked for an e2e/integration job that exercises a built module through the ABI. Option (a) — a Rust integration test driving a module via the host feature — already exists for ratelimit and maintenance-mode, but both only assert the fail-OPEN CONTINUE verdict. I extended that pattern to the opposite, security-relevant path:

crates/ephpm-middleware-ip-allowlist/tests/deny.rs drives the shell crate's IpAllowlist (the crate that becomes the shipped cdylib) through the host feature's RequestCtx / host_table() and asserts the fail-CLOSED verdict — a real 403 RESPOND (action, status, and non-empty body), plus deny-beats-allow. It needs no ephpm binary and no KV store (the verdict is pure CIDR policy), so it is deterministic and never flaky — exactly the boundary the task preferred.

Why not a true downloaded-binary e2e (option b): it would need a released ephpm whose ABI major matches this repo's pinned rev, a mounted cdylib, and a live curl — heavy and flaky (release availability + ABI-major skew) for no coverage the in-process ABI test doesn't already give. The host-feature integration test is the right boundary; a full e2e belongs to the release/host repos, not this PR gate.

Verification

Ran the exact workflow commands locally (shared target cache, CARGO_NET_GIT_FETCH_WITH_CLI=true), all green:

• cargo +nightly fmt --all -- --check — clean
• cargo clippy --workspace --all-targets -- -D warnings — clean (-D warnings not weakened)
• cargo test --workspace — 80 unit + ratelimit fail_open (1) + maintenance-mode fail_open (1) + new ip-allowlist deny (2) = 84 tests, 0 failures
• cargo build --workspace --release — all 8 cdylibs link

This PR is the first to exercise the new workflow.