Spec gap: no canonical error for failed push notification config retrieval

## Summary
`getTaskPushNotificationConfig` / `listTaskPushNotificationConfigs` have no canonical error defined for the case where the requested push notification config (or the task's config list) does not exist.

## Problem
The A2A spec defines error codes for task operations (e.g. `TaskNotFoundError` for a missing task) but nothing equivalent for push notification configs. SDK implementations therefore diverge:

| SDK | Missing push config behavior |
|-----|------------------------------|
| Python | `-32001` (TaskNotFoundError class) / HTTP 404 |
| Java | `TaskNotFoundError` |
| JavaScript | bare internal error → HTTP 500 |
| Go | internal error → HTTP 500 / gRPC Internal |
| Rust | N/A (transport under review) |

A client cannot reliably distinguish "config does not exist" from "server error" across implementations.

## Proposal
Define a canonical error for push-notification-config operations on non-existent configs/tasks, e.g.:
- A spec-level error name and code (or a documented reuse of the task-not-found class for config operations), and
- Consistent HTTP/gRPC status mappings (404 / NOT_FOUND).

## Why it matters
SDKs need a single, spec-conformant mapping to implement; clients need stable error semantics when e.g. polling for a config that was deleted.