Typed context APIs to eliminate no-explicit-any in extension models

Problem Statement

Extension models that use context.dataRepository.getContent() are forced into pervasive // deno-lint-ignore no-explicit-any annotations because:

1. getContent() returns Uint8Array | null, requiring manual JSON.parse(new TextDecoder().decode(raw)) which produces an untyped result
2. The parsed data must be cast as any to access properties like .accessories
3. Callback parameters in methods like .find() on the parsed data need their own any annotations
4. Pairing data retrieved via getContent() needs as any to pass to typed functions like pairVerify()

In the @bixu/homekit extension, this results in 10+ lint-ignore comments across 3 methods, all stemming from the untyped getContent() return value. The deno fmt tool also moves as any casts to different lines than their lint-ignore comments, causing ban-unused-ignore errors that require additional workarounds.

Proposed Solution

Provide a typed readResource<T>() method on the context that:

• Accepts a resource spec name and instance name
• Returns the parsed, vault-resolved object typed against the spec's Zod schema
• Eliminates the need for manual JSON decode, vault resolution, and as any casts

This builds on #708 (add context.readResource()) and #709 (return parsed objects). The key addition here is that the return type should be inferred from the resource spec's Zod schema, so extension authors get type safety without casts.

Scope of changes:

• MethodContext: add generic readResource<T>(specName, instanceName) that infers T from the spec schema
• Data repository: handle JSON deserialization and vault expression resolution internally
• Extension model documentation: update examples to use the typed API
• This would eliminate the need for as any casts and their associated lint-ignore comments in well-structured extension models

Alternatives Considered

• Disable the no-explicit-any lint rule in extension models — hides real type issues
• Export helper functions for typed parsing — still requires manual wiring and doesn't integrate with vault resolution
• Use z.infer types manually — possible but verbose, and doesn't help with the getContent return type