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.

Review the A2A specification for error handling, particularly around task operations and push notification configs. Examine the SDK implementations (Python, Java, JavaScript, Go) to see how they currently handle missing configs. The goal is to propose a spec change that defines a canonical error, such as extending TaskNotFoundError or creating a new error code, and ensure consistent HTTP/gRPC mappings.

Vom Indexierungsmodell aus dem Issue-Text verfasst.