MeshSync discovery: tiered & user-configurable depth/scope (design)

Nobody has claimed this yet.

## Summary
Replace MeshSync's flat, all-or-nothing discovery (one informer per kind over a hardcoded ~66-resource list, all namespaces, full fidelity) with a three-tier funnel that is user-configurable per connection for depth and scope:
- **Tier 1** cheap/broad presence detection, **Tier 2** deeper per-object inspection, **Tier 3** infrastructure-specific deep discovery activated only when that infrastructure is detected present (optionally delegated to adapters over NATS).
- Depth is a per-kind projection (shallow = ObjectMeta only; full = today's behavior), trimmed at publish time - no new wire shape.

## Key decisions
- Whitelist/blacklist becomes a degenerate tier config (full back-compat).
- Schema-first: a typed tier/depth contract surfaced via the MeshSync CRD (meshery-operator) plus a per-connection override in Connection metadata (meshery/schemas), with a Server API + UI controls.
- Fixes a real operability gap found along the way: editing the MeshSync CR's `watch-list` currently requires a pod restart (no live reload). This adds a CR-watch hot-reload path - independently valuable and worth extracting as its own change.

## Scope / phasing
MVP: depth toggle + tier config parsing + CR hot-reload (~1.5-2 wks across repos). Full: infra detection + conditional Tier-3 + adapter delegation.

**Scale note:** depth-trimming cuts publish/DB cost but not informer cache/watch memory; true cluster-scale relief needs metadata-only or namespace-scoped informers (separate).

## Full design
[docs/design/fd1-tiered-configurable-discovery.md](https://github.com/meshery/meshsync/blob/master/docs/design/fd1-tiered-configurable-discovery.md) (added in #576) - current-state analysis, per-repo file changes, schema/CRD/API changes, sequencing, test plan, and open questions.

Start with docs/design/fd1-tiered-configurable-discovery.md, which contains the current-state analysis, per-repo file changes, sequencing, test plan, and open questions. Review the MVP scope of depth toggles, tier parsing, and CR hot-reload, then use the referenced schema, CRD, API, and UI changes to define the implementation boundary. Done means the planned MVP behavior and tests are covered across the affected repositories.

Written by the indexing model from the issue text.