Support Taskflow-like syntax in the Go SDK

### Background

Today a Go task function takes `ctx`, an `sdk.Client` / `sdk.VariableClient`,
and a `*slog.Logger`, and pulls XCom data explicitly:

```go
// go-sdk/example/bundle/main.go
func transform(ctx context.Context, client sdk.VariableClient, log *slog.Logger) error {
val, err := client.GetVariable(ctx, "my_variable")
...
}
```

Java has just landed Taskflow-style task signatures under #66332, where
the upstream task's return value is declaratively injected into the
downstream task's parameter list rather than pulled via the client. We
want the same shape in Go so authors can write:

```go
func extract(ctx context.Context) (SomeType, error) { ... }
func transform(ctx context.Context, upstream SomeType) error { ... }
```

### What needs to happen

1. Decide how to declare task-to-parameter wiring in `Registry.AddTask`
(does `depends []string` carry positional binding, or do we use typed
task handles returned by `AddTask`?).
2. Use reflection in `bundlev1.NewTaskFunction` to recognise an extra
typed parameter and treat it as an XCom pull from the named upstream.
3. Serialise the binding into the Dag JSON in coordinator-mode so the
supervisor knows which XCom to feed in.
4. Update `example/bundle/main.go` to a Taskflow-style example.

### Acceptance criteria

- A Go task can declare an upstream-typed parameter and receive the
upstream's return value at execution time without calling
`client.GetXCom` explicitly.
- Serialisation matches what the Python supervisor expects for a
Taskflow-wired Dag (validated against `test_dags.yaml`).
- The existing client-pull pattern remains supported.

### Context

- Java parallel: #66332 (Done).
- `@task.stub` argument-passing groundwork: #66330 (Done).
- Same area as task dependency representation: #66331.