pkg/model.KubernetesResource is not schema-driven and mixes wire casing

## Current Behavior

MeshSync's canonical wire/DB model - `pkg/model.KubernetesResource` and its siblings (`KubernetesResourceObjectMeta`, `KubernetesResourceSpec`, `KubernetesResourceStatus`, `KubernetesKeyValue`) - is a local Go/GORM struct defined and maintained entirely inside this repo. It is not sourced from `github.com/meshery/schemas`, the ecosystem's shared schema repository that meshery-cloud and (increasingly) other Meshery services consume as their single source of truth for wire/DB contracts.

Two concrete problems follow from that:

1. **No single source of truth.** Meshery Server consumes this model over the NATS stream MeshSync publishes to, and effectively re-derives its own understanding of the same shape (e.g. `server/models/meshsync_events.go` in `meshery/meshery`). Because neither side generates from a shared schema, the two can drift silently - a field renamed or retyped in one repo has no automated check (no `consumer-audit` equivalent) that would catch a mismatch in the other before it reaches production.
2. **Mixed wire casing today.** The ecosystem-wide contract (`meshery/schemas/AGENTS.md § Casing rules at a glance`, restated in this repo's [`docs/agent-instructions/naming-conventions.md`](https://github.com/meshery/meshsync/blob/master/docs/agent-instructions/naming-conventions.md)) is: *wire is camelCase everywhere; DB is snake_case; the ORM layer is the sole translation boundary.* `pkg/model.KubernetesResource` violates this today - most JSON tags are camelCase (`apiVersion`, `resourceVersion`, `generateName`), but several are snake_case (`cluster_id`, `unique_id`, `pattern_resource`, `component_metadata`), left over from whenever those fields were added. This is confusing for API consumers and is the kind of drift the schemas migration exists to prevent going forward.

## Desired Behavior

Migrate `pkg/model.KubernetesResource` (and its siblings) into `github.com/meshery/schemas`, following the repo's Dual-Schema Pattern (a response entity schema plus a `*Payload` schema for any writable path, if applicable), so that:

- The Go struct here, the TypeScript types (if any consumer needs them), and Meshery Server's own model are all generated from one canonical OpenAPI definition.
- The wire casing is resolved deliberately as part of the migration - camelCase throughout - rather than left mixed. Per `schemas/AGENTS.md`, this is **not** a place for a silent partial recase; a wire-format change like this needs either a coordinated single-shot migration (updating every consumer in the same change) or a new API version, decided explicitly as part of the migration design.
- Once migrated, `cd ../schemas && make validate-schemas && make consumer-audit` becomes a real, meaningful check for MeshSync PRs (today it is not, since nothing here is schemas-sourced - see the "Schema-aware changes" note in [`AGENTS.md`](https://github.com/meshery/meshsync/blob/master/AGENTS.md)).

## Scope / Coordination

This is a cross-repo change, not a MeshSync-only one:

- **`meshery/schemas`** - author the new construct(s), following the existing `Dual-Schema Pattern` and canonical reference implementations in that repo.
- **`meshery/meshsync`** - consume the generated Go type in `pkg/model`, updating `model_converter.go` / `preprocessor.go` and every `internal/output` writer that depends on the current shape.
- **`meshery/meshery`** - the NATS consumer and any persisted-model code (e.g. `server/models/meshsync_events.go`) needs the same coordinated update, since it is currently deriving its own understanding of this wire shape independently.

Given the coordination required and the wire-breaking nature of resolving the casing, this should be scoped and designed before implementation - filing as `kind/proposal` rather than jumping straight to `kind/enhancement`.

## References

- [`docs/agent-instructions/naming-conventions.md`](https://github.com/meshery/meshsync/blob/master/docs/agent-instructions/naming-conventions.md) (added in #572) - documents this exact divergence and states the "no silent recasing" rule that applies here.
- [`meshery/schemas` docs: casing rules](https://github.com/meshery/schemas/blob/master/docs/casing-rules.md) and the [identifier-naming contributor guide](https://github.com/meshery/schemas/blob/master/docs/identifier-naming-contributor-guide.md).
- `pkg/model/model.go` in this repo - the struct definitions in question.