feat: add edge-cloud capability contract extension

[catyans]

Summary

Add an experimental A2A extension sample for machine-readable edge-cloud task placement and governance:

• normative v1 specification using existing A2A extension negotiation and metadata
• JSON Schemas for CapabilityContract, ExecutionRequirements, and ExecutionReceipt
• dependency-free, fail-closed reference matcher
• tests for offline/edge residency selection and rejection when latency, region, attestation, verification, or idempotency constraints cannot be met

This follows the proposal workflow in a2aproject/A2A#2076 and the sample discussion in #648. It does not change core A2A types or claim an official a2a-protocol.org extension URI.

Design boundaries

• capability declarations and receipts are claims, not trust anchors
• the extension does not replace TLS, authentication/authorization, Agent Card signatures, attestation verification, or local policy
• requirements are checked before declared side effects; they are never silently relaxed
• raw credentials, private topology, and sensitive content are prohibited from extension metadata
• MCP tool annotations may inform stricter requirements but are not treated as cross-agent attestation

Validation

Local:

• ruff check passes
• 7/7 focused tests pass
• all three schema documents parse as JSON
• git diff --check passes

Remote H20 smoke (lingjun-101):

• direct clone of commit cc5232a
• Python 3.12 compileall passed in an existing task-owned one-shot container
• executed the matcher with restricted data, edge-only region, offline mode, idempotency key, attestation, and verification constraints; selected the compatible edge site

The host Python is older than this repository's Python 3.12 requirement and has no pytest, so the full unit suite is reported from the local environment; remote validation is intentionally labeled smoke.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[catyans]

CI note: Lint Code Base passed. The failing Lint Go job did not report any path changed by this PR; it failed on two pre-existing files:

• samples/go/agents/helloworld/test_client.go:34 — unchecked resp.Body.Close()
• samples/go/agents/sign-and-verify-agent-card/test_client.go:33 — unchecked resp.Body.Close()

This PR adds only Markdown, JSON Schema, and Python under extensions/edge-cloud-capability-contract/. I am not changing those unrelated Go samples in this extension PR.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[catyans]

CI follow-up: both checks are now green. The dedicated Go lint job validates each nested module independently, while Super-Linter no longer combines changed files from different Go modules into one invalid golangci-lint invocation.

[catyans]

Resolved the current main conflicts in 5a9973a. Both conflicts were formatting-only changes to unrelated Go response-body cleanup; the resolution keeps the current upstream one-line form. The edge-cloud contract test suite passes locally (7 passed).

[catyans]

Follow-up CI fix in b6b7754: the merge brought upstream’s VALIDATE_GO / VALIDATE_GO_MODULES entries into the same workflow where this branch already defined them, producing duplicate YAML keys and preventing GitHub Actions from creating jobs. Removed the duplicate pair; each key now appears once. The focused contract suite still passes (7 passed).

[Silentpartnercoding]

I think the receipt can be schema-valid for a different request than the one a verifier is checking. contractDigest binds the advertised capability and resultDigest binds the output, but the receipt does not bind the exact ExecutionRequirements, extension activation/version, or A2A message/task correlation. idempotencyKeyDigest is optional even for side-effecting executions.

Could v1 require a canonical requirementsDigest, define which A2A correlation fields are covered, and require idempotencyKeyDigest whenever sideEffects.kind != "none"? A negative fixture could execute under a permissive request, then replay that receipt against a request with a stricter region, network mode, or attestation requirement and require verification to fail before any trust decision.

There is also a smaller fail-closed mismatch in contract.py: any unknown networkMode currently falls through as connected because only "offline" has behavior. The reference matcher should reject values outside connected | degraded | offline, with a focused negative test.

This keeps the current “receipt is evidence, not proof” boundary; it just makes the evidence refer to the request it claims to satisfy.