add API V3 keyspace identity protos

[disksing]

Summary

• Add public API V3 KeyspaceIdentity schema and wire it through KV, PD, TSO, keyspace, GC, and related tenant-scoped protobuf APIs.
• Preserve legacy keyspace_id fields for V1/V2 compatibility while documenting V3 identity semantics.
• Update generated bindings and proto metadata for downstream API V3 consumers.

Validation

• make proto-fmt
• go build ./pkg/...
• go test ./pkg/...
• make check reached the expected proto.lock change prompt
• cargo check is still blocked locally by the known libz/Xcode header issue

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign cfzjywxk, rleungx, tiancaiamao, windtalker, yudongusa for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS
• proto/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rleungx]

Changing this existing scalar field into a oneof is source-incompatible for generated Go users even though the wire tag is preserved. Context.KeyspaceId disappears, and downstream PD/TiDB/client-go code constructs or reads this field directly, so upgrading kvproto would break V1/V2 callers that do not use V3. The legacy scalar should stay as a normal field and keyspace_identity should be added alongside it, as was done for AutoIDRequest and KeyspaceMeta.

[disksing]

Thanks, fair point. I originally kept keyspace_id as a normal field and added keyspace_identity alongside it to minimize downstream Go source changes. Later I changed it to oneof based on review feedback, since semantically it is clearer that only one keyspace identifier should be set.

I think both directions are reasonable: parallel fields are more source-compatible, while oneof is clearer semantically. @sunxiaoguang what do you think? If we prefer minimizing downstream changes for kvrpcpb.Context, I can change this back to the parallel-field style.