Support dynamic per-task rate limiting via StartWorkflowRequest

## Summary

Currently, task rate limits are statically defined in TaskDef. There is no way to override rate limits per workflow execution at runtime. This is needed when different clients or use cases require different rate limits for the same task type.

## Desired Behavior

Allow `StartWorkflowRequest` to include optional `taskRateLimitOverrides` that override static TaskDef rate limits for that workflow execution:

- Overrides keyed by reference task name (most specific) or task definition name
- Task mappers check for overrides before falling back to static TaskDef values
- Existing Redis rate limiting infrastructure works unchanged with dynamic values

## Scope

- `StartWorkflowRequest` — new `taskRateLimitOverrides` field
- `WorkflowModel` — carry overrides through execution
- Task mappers (`SimpleTaskMapper`, `HTTPTaskMapper`, `KafkaPublishTaskMapper`, `UserDefinedTaskMapper`, `DoWhileTaskMapper`) — check overrides
- New `TaskMapperUtils` utility for override resolution
- gRPC proto update for `StartWorkflowRequest`

## Prior Art

Community PR #569 by @hchepey-clari implemented this as a 731-line change with tests. The approach was clean but will need rebasing against current main.

Start with StartWorkflowRequest and the gRPC proto, then trace how WorkflowModel carries execution settings into SimpleTaskMapper, HTTPTaskMapper, KafkaPublishTaskMapper, UserDefinedTaskMapper, and DoWhileTaskMapper. Review the prior PR #569 for implementation context. Done means reference task name overrides take precedence over task definition overrides, all mappers fall back to static TaskDef values, and existing Redis rate limiting remains unchanged.

Written by the indexing model from the issue text.