chore(deps): bump openeverest core to v2.0.0-dev.2

[recharte]

What

Bumps github.com/openeverest/openeverest/v2 from v2.0.0-dev.1.0.20260721150452-3ea180918896 (2026-07-21) to the tagged release v2.0.0-dev.2 (c9002768).

go.mod / go.sum only. No source changes were required.

Why

The old pin is roughly three weeks of core development behind, and predates several API changes that reshape what a provider is compiled against:

• PITR / DataSource restructuring. In api/backup/v1alpha1/restore_types.go, DataSourcePITR / PITRType became DataSourcePointInTime / RecoveryTarget, and a new StreamSource type identifies the backup stream to recover from. api/core/v1alpha1/instance_types.go gained InstanceBackupStoragePITRStatus and PITRState.
• Provider CRD schema move (Secret definitions in Provider CRD uses parameters schema openeverest#2616). Provider.spec.secrets[].openAPIV3Schema moved down a level to .parametersSchema.openAPIV3Schema - in Go, SecretDefinition.OpenAPIV3Schema *apiextensionsv1.JSONSchemaProps became SecretDefinition.ParametersSchema *common.ParametersSchema, matching how components, topologies and BackupClasses already declare schemas. SecretDefinition.Validate() and ErrSecretSchemaValidation were removed in favour of the equivalents on the shared common.ParametersSchema. Provider.spec.configMaps and Provider.spec.release were added.
• provider-runtime changes in controller/common.go, controller/backup_validation.go, the new controller/config_map_validation.go, reconciler/provider.go and reconciler/restore.go.

Until it is rebuilt against v2.0.0-dev.2, this provider does not reconcile against current core.

Impact on this provider

None at the source level.

• definition/provider.yaml declares no secrets: block (it defines a single server component of type vllm with parametersSchema: VllmParameters), and no Go file references SecretDefinition, OpenAPIV3Schema or ErrSecretSchemaValidation. The schema rename is therefore inert here.
• This provider does not implement BackupProvider, so the PITR / DataSource restructuring does not reach it.
• Its only core imports are api/core/v1alpha1, provider-runtime/controller and provider-runtime/reconciler; none of the changed signatures affect its call sites.

The rest of the go.mod movement is MVS following core's own requirements, not an independent upgrade: go 1.26.2 -> 1.26.3, k8s.io/* 0.36.0 -> 0.36.3, sigs.k8s.io/controller-runtime 0.24.0 -> 0.24.1, github.com/getkin/kin-openapi 0.138.0 -> 0.145.0, github.com/go-openapi/jsonpointer v0.23.1 -> v1.0.0. The latter two drop mailru/easyjson, josharian/intern, perimeterx/marshmallow, mohae/deepcopy and woodsbury/decimal128 from the indirect set.

Regenerated

make generate was re-run end to end (controller-gen RBAC, Helm RBAC sync, go generate for the provider spec). It produced no diff: config/rbac/role.yaml, charts/provider-kubeai/generated/provider-spec.yaml and the generated RBAC rules are byte-identical to main. make verify would pass.

Verified

• go build ./... - clean, no compile breakage
• go vet ./... - clean
• make generate - clean, no diff beyond go.mod / go.sum
• make lint - 0 issues (golangci-lint v1.63.4)
• make test - exits 0, but this repo currently contains zero _test.go files, so that result is vacuous and should not be read as coverage of the bump

Chainsaw integration tests were not run (they need a cluster); CI covers them.

Follow-up

This PR does not cut a provider release - no chart version / appVersion bump, no tag, no publish. A maintainer still has to cut a provider-kubeai release after this merges so the new core is actually shipped.