feat: add AppK8sClient for KService lifecycle management

[AdilFayyaz]

Depends on: #7161

Why are the changes needed?

The App Service needs a K8s client to manage the full lifecycle of Knative KService CRDs — the single source of truth for app spec and status. This PR lays the infrastructure foundation and implements the core client.

What changes were proposed in this pull request?

• Implement AppK8sClient in app/internal/k8s/app_client.go with full AppK8sClientInterface: Deploy (create/update KService with spec-SHA change detection), Stop (max-scale=0), Delete (remove KService), GetStatus (map KService conditions → proto), List, GetReplicas, DeleteReplica, and Watch (fan K8s watch events → WatchResponse channel)
• Moved the config from actions to app/

How was this patch tested?

• go test ./app/internal/k8s/... -count=1 — 14 unit tests using controller-runtime fake client covering all interface methods
• go build ./... — full repo build passes
• Key cases covered: idempotent deploy (spec-SHA skip), stop vs delete semantics, not-found handling, pod status mapping, watch event type routing (Added/Modified/Deleted/Error/Bookmark)

Setup process

Screenshots

Check all the applicable boxes

• I updated the documentation accordingly.
• All new and existing tests passed.
• All commits are signed-off.

Related PRs

Docs link

• main
  • Flyte 2 WIP #6583
    • feat: add AppK8sClient for KService lifecycle management 👈
      • feat: implement InternalAppService for Knative app lifecycle #7175
        • feat: implement AppService control plane proxy with TTL cache #7176
          • feat: resilient Watch RPC with reconnect and resourceVersion tracking #7188
            • feat: path based ingress routing for Flyte apps via Traefik + Knative #7197

[pingsutw]

I think we should get the replica from kservingv1.Revision

[AdilFayyaz]

I can pull it from the latest revision, but would there ever be a case that we have multiple revisions running at the same time? Each would then have it's own active pods