[Proposal] Stop ctx.Value from being an implicit RPC parameter source

Parent issue: #3595

## Problem

The client invocation path currently treats `ctx.Value(constant.AttachmentKey)` as an implicit source of RPC attachments. In `client.generateInvocation`, values stored in the Context are copied into `Invocation.attachments` and may then be serialized as Dubbo attachments, Triple HTTP headers, or Dubbo3/gRPC metadata.

This means a call such as:

```go
ctx = context.WithValue(ctx, constant.AttachmentKey, map[string]any{
"tenant-id": "tenant-a",
})
client.CallUnary(ctx, req, resp, "GetUser")
```

has hidden RPC inputs that are not visible in the call options or business request. The same mechanism can also affect RPC control fields such as timeout and retries.

The server side may expose inbound metadata both through `ctx.Value(constant.AttachmentKey)` and through `Invocation.attachments`, which further blurs the boundary between request lifecycle context and transport metadata.

## Goals

- Make outbound RPC metadata explicit at the call site.
- Keep `context.Context` focused on cancellation, deadlines, tracing, and local request-scoped state.
- Preserve existing users through a documented compatibility path.
- Ensure explicit metadata has deterministic precedence over legacy metadata.
- Prevent a metadata timeout from extending the caller's Context deadline.

Read parent issue #3595 and trace client.generateInvocation, focusing on how context.Value(constant.AttachmentKey) reaches Invocation.attachments and transport metadata. Identify the existing outbound and server-side metadata paths before defining the compatibility behavior. Done should satisfy the listed goals for explicit metadata, precedence, and context-deadline handling.

Written by the indexing model from the issue text.