enhancement(registry): fail closed consistently on malformed record payloads

## Context

Follow-up from the final review of PR #779.

The TypeScript and Python Agent Registry adapters do not handle malformed or out-of-band record payloads consistently. These cases are uncommon, but the registry contract is intended to fail closed rather than leak raw parser errors or let one corrupt record disrupt an entire namespace.

## Problems

- TypeScript eagerly extracts every record returned by `listRecords`. A malformed JSON payload throws a raw `SyntaxError`, so one corrupt record can prevent resolution or immutability checks for otherwise healthy records in the same namespace.
- Python's CUSTOM path handles a missing `data` key but not an explicit `null`; `json.loads(None)` raises `TypeError`, which the resolution boundary does not catch.
- Corrupt SKILL frontmatter can silently erase publisher provenance through `parseSkillPublisher`.
- Registry status values are currently coerced into `RegistryStatus` without runtime validation.

## Desired behavior

- Resolving a selected record with an unreadable payload fails with the port-owned `REMOVED` error rather than a raw parser exception.
- An unrelated corrupt record does not prevent healthy records in the same namespace from resolving.
- A corrupt record at matching coordinates must not bypass publish immutability.
- TypeScript and Python adapters apply equivalent fail-closed behavior for CUSTOM, MCP, and SKILL payloads, including explicit null values.
- Publisher provenance and unknown status handling are explicit rather than silently discarded or coerced.

## Tests

Add direct tests for:

- Malformed and explicit-null CUSTOM/MCP bodies.
- Corrupt and duplicate-key SKILL frontmatter supplied directly to the read-side parser.
- A healthy record coexisting with an unrelated corrupt record.
- A corrupt record at the same publish coordinates.
- Unknown service status values.

## References

- PR #779
- `cdk/src/handlers/shared/registry/agent-registry-client.ts`
- `agent/src/registry/agent_registry_client.py`

Inizia leggendo cdk/src/handlers/shared/registry/agent-registry-client.ts e agent/src/registry/agent_registry_client.py, quindi esamina la PR #779 per verificare i confini del registry esistenti. Aggiungi i test diretti elencati per i casi malformati, null, corrotti, con chiavi duplicate, con record duplicati e con stato sconosciuto. Il lavoro è completato quando entrambi gli adapter falliscono in modo equivalente e fail closed, preservano la provenienza del publisher, isolano la corruzione non correlata e applicano l’immutabilità alle coordinate corrispondenti.

Scritto dal modello di indicizzazione a partire dal testo della issue.