Added the temporal channel command group. - #4

This PR adds temporal channel, lists a Workflow's channels in workflow describe and lets the dev server call local callback listeners.

What changed?

• temporal channel notify, describe, poll, listener add and listener remove. -c names the channel. With --workflow-id or --activity-id and an optional --run-id it's the channel linked to that execution, sent as the request's execution. Without an owner it's the independent channel of that name.
• notify takes --position, --counter and --metadata KEY=VALUE with JSON values and prints how many listeners it reached. describe shows the kind, the owner line, what's retained and both listener tables. poll waits up to --wait above --after-counter, and --follow keeps going from the last counter seen. listener add takes a callback URL with --header values and prints the ID listener remove takes.
• A missing channel, a linked channel whose owner isn't running and the server's limits come back in plain words, with the server's message after them. The error type is refusalError in refusal.go, and payloadText joins payload.go, so the stream commands can share both later.
• temporal workflow describe prints a Notification Channels table when the Workflow listens on any.
• temporal server start-dev allows callbacks to 127.0.0.1 and localhost on any port over plain HTTP. --dynamic-config-value 'callback.allowedAddresses=...' still replaces the list.

Part of AI-198 (epic AI-37).

Why?

It gives the notification channel a terminal front. You can play a writer with notify, a client listener with poll and a callback listener with listener add, and describe shows what the server holds. The channel calls are public WorkflowService calls, so the SDK client and its codec interceptor cover them with no new plumbing. The server calls no callback address until one is allowed, and upstream allows none by default. A local receiver rarely serves TLS, so the dev server allows local addresses out of the box.

How did you test it?

Link to a test plan if any -

• Unit Tests
• Staging
• End to End Tests

The TestChannel unit tests run each command against an in-process fake of the workflow service: flag checks that send nothing, the request each command sends with either owner, text and JSON output, --follow, the plain refusals and the workflow describe table. The TestChannel suite cases run on the shared dev server. They cover retention without listeners, folding a stale counter, a poll that waits, a callback round trip, an unknown channel, and linked channels on a running Workflow and on a standalone Activity. I ran the rest of SharedServerSuite and the other packages too, since the server module moved. go mod tidy and the generators leave no diff. By hand on temporal server start-dev --headless, I ran every command on an independent channel and again with --workflow-id on a running Workflow, including workflow describe and the refusal after it was terminated.