Implement CARD-SIGN-* agent card signing conformance tests (TASK-29)

## Summary

I'd like to implement the agent-card signing conformance coverage tracked internally as **TASK-29** (`backlog/tasks/task-29 - Add-agent-card-signing-conformance-tests-CARD-SIGN.md`). The four `CARD-SIGN-*` requirements in `tck/requirements/agent_card.py` are currently declared but tagged `not-automatable` with no validators, and they came back **NOT TESTED** in the April full-TCK run.

Opening this first to confirm appetite and direction before sending a PR.

## Proposed scope

Aligning to the **current registry** definitions (the per-ID summaries in the backlog note predate the present `CARD-SIGN` requirements, so I'd follow the code):

- **CARD-SIGN-003** (§8.4.2) — decode each `signatures[].protected`; assert `alg` and `kid` are present and `alg` is one of the spec's named JWS algorithms. Pure structural, offline.
- **CARD-SIGN-001 + CARD-SIGN-002** (§8.4.1) — verify together by reproducing the §8.4.3 verification algorithm: exclude `signatures`, remove proto-default-valued properties (per §8.4.2 step 1 / §8.4.3 step 3, driven by the bundled `AgentCard` descriptors), JCS-canonicalize (RFC 8785), and verify the detached JWS against the key resolved from `kid`/`jku`. A passing verification demonstrates conformant JCS canonicalization with `signatures` excluded.
- **CARD-SIGN-004** (§8.4.3, expired/revoked keys) — would stay `not-automatable` (key lifecycle state isn't derivable from a card), with a rationale comment.

Tests would **skip when the card carries no `signatures[]`** (signing is `MAY` at §8.4), consistent with the task's own note that signing tests may be skipped when a SUT doesn't implement signing.

## Open questions for maintainers

1. **Dependencies.** Verification needs JCS + JWS. I'd add an **optional** extra (`signing = ["jwcrypto", "rfc8785"]`) with import-guarded skips so the base kit stays dependency-minimal. Is an optional extra acceptable, or do you prefer these as core deps / a different library?
2. **Key resolution.** OK to fetch a `jku` JWKS over HTTPS during the live-SUT run (network I/O the kit already does), with an injectable boundary for offline unit tests, and treat "no resolvable key" as inconclusive rather than fail?

Happy to send a focused, single-purpose PR with unit + compatibility tests if this direction looks right.