feat: Add CallerType for request context propagation

[fimanishi]

What changed?
Added CallerType infrastructure for client identification:

• Added CallerType enum with CLI, SDK, UI, Internal, and Unknown variants in common/types
• Added context helpers WithCallerType() and GetCallerType() for propagating caller type through request context
• Added ParseCallerType() for string-to-enum conversion and String() for enum-to-string conversion
• Added CadenceRequestsWithoutCallerType metric for tracking adoption

Why?
Enable client-aware operations:
Cadence currently has no visibility into which client type (CLI, SDK, UI, Internal) is making requests. This enables future capabilities like per-client-type rate limiting, client-specific features, and improved observability.

How did you test it?
Unit tests.

Potential risks
None - this change only adds type definitions and helpers without any usage. No behavior changes.

Release notes
N/A - internal infrastructure only

Documentation Changes
N/A

[davidporter-id-au]

Question: This category is like 'getHistory' calls via the worker client library, for example? This refers to indirect API calls triggered by customer workers and direct API calls to say, 'StartWorkflow' via the client libraries?

[fimanishi]

This is the intention, yes. But how it'll depend on how the caller type is added to the context

[davidporter-id-au]

Nit: This is, I assume, direct YARPC API calls?

[fimanishi]

this would be any calls that are initiated by the services and not by cli/sdk/UI. We will propagate the caller type in the context so requests downstream will maintain the initial caller type

[davidporter-id-au]

as discussed in slack, this is presumably mostly intra-service calls. Imho we might need a slightly more descriptive name for this, indicating it's internal to the Cadence cluster (or clusters, in the case of replication).

[fimanishi]

renamed from "service" to "internal"

[davidporter-id-au]

lgtm other than that renaming thing