Add WebAuthn (secp256r1/P-256) signature verification for passkey support

## Summary

Add support for secp256r1 (P-256/prime256v1) signature verification to enable WebAuthn/passkey-based authentication alongside the existing secp256k1 ECDSA scheme.

Passkeys eliminate seed phrases and leverage device-native authentication (biometrics, PIN), significantly improving UX for end users.

## Motivation

- **UX**: Passkeys are the industry direction for wallet auth — no seed phrases, no browser extensions, built into every modern OS and device.
- **Adoption**: WebAuthn is supported by all major browsers and platforms (Apple, Google, Microsoft). Billions of devices already have P-256 hardware support.
- **Account Abstraction alignment**: Supporting multiple signature schemes is a natural fit for account-driven architectures.

## Scope

1. **P-256 signature verification** — Add `ecrecover` equivalent for secp256r1 in the STF.
2. **WebAuthn payload parsing** — Decode authenticator data + client data JSON per the WebAuthn spec.
3. **Gas/fee metering** — Price r1 verification appropriately (see tradeoffs).
4. **Authentication module** — Extend or create an auth account that supports both k1 and r1 signers.

## Performance Tradeoffs

### secp256r1 is slower than secp256k1 in pure software

On-chain verification is pure software (deterministic STF), so hardware acceleration is not available. Expected overhead:

| Aspect | secp256k1 | secp256r1 |
|--------|-----------|-----------|
| Point doubling | Faster (a=0 in y²=x³+7) | Slower (a=-3 in y²=x³-3x+b) |
| Scalar multiplication | GLV endomorphism (~30% speedup) | No equivalent optimization |
| Software verification | Baseline | **~20-40% slower** |
| Library maturity | libsecp256k1 (extremely optimized) | Good (p256, RustCrypto) but less specialized |

### Implications

- **Gas pricing**: r1 `ecrecover` must be priced higher than k1 to reflect actual compute cost. Underpricing creates a DoS vector.
- **Throughput**: At sub-millisecond per verification, the per-tx overhead is small. Becomes relevant only at very high TPS where signature verification dominates block processing time.
- **Block gas limits**: If r1 txs consume more gas per signature, fewer r1-signed txs fit per block compared to k1.

### Where r1 wins (client side, not on-chain)

- Signing happens in secure enclave/TPM with hardware P-256 — effectively instant from user perspective.
- No private key management burden on the user.

## Implementation Considerations

- Use `p256` crate (RustCrypto) for verification — pure Rust, no C dependencies, audited.
- WebAuthn payloads include additional fields (challenge, origin, authenticator data) that must be parsed and validated deterministically.
- Consider whether to support both raw P-256 ECDSA and full WebAuthn envelope, or only WebAuthn.
- Signature malleability: enforce low-S normalization same as k1.

## References

- [WebAuthn spec (W3C)](https://www.w3.org/TR/webauthn-3/)
- [EIP-7212: Precompile for secp256r1](https://eips.ethereum.org/EIPS/eip-7212)
- [RustCrypto p256 crate](https://crates.io/crates/p256)