dfdaemon logs caller credentials from Download payload at info level

[YQ-Wang]

Bug report:

dfdaemon logs the full incoming Download protobuf payload with {:?} at info level in the gRPC download_task handlers.
The Download payload can contain caller-supplied credentials, including:

• object_storage.access_key_secret
• object_storage.session_token
• object_storage.security_token
• object_storage.credential_path
• hdfs.delegation_token
• hugging_face.token
• model_scope.token
• Sensitive request headers such as Authorization, Cookie, and X-Amz-Security-Token
  Because the generated protobuf structs use the default derived Debug implementation, these values are printed verbatim to dfdaemon logs when the log level is info.
  Relevant log sites include:
• dragonfly-client/src/grpc/dfdaemon_download.rs: info!("download task started: {:?}", download);
• dragonfly-client/src/grpc/dfdaemon_upload.rs: info!("download task started: {:?}", download);
  This is especially visible when using dfget with object storage credentials, because dfget passes those credentials to dfdaemon through the gRPC Download message.

Expected behavior:

dfdaemon should not write plaintext caller credentials to logs.
The log entry can preserve operationally useful request metadata, but sensitive credential fields and sensitive request headers should be redacted before formatting the Download payload.

How to reproduce it:

1. Run dfdaemon with log level info.
2. Use dfget to download from an object-storage URL while passing credentials, for example with placeholder values:

dfget \
  --url 's3://example-bucket/path/to/object' \
  --output /tmp/object \
  --storage-region us-east-1 \
  --storage-access-key-id AKIAEXAMPLE \
  --storage-access-key-secret EXAMPLE_SECRET_ACCESS_KEY \
  --storage-session-token EXAMPLE_SESSION_TOKEN \
  --transfer-from-dfdaemon

3. Inspect the dfdaemon log:
   grep 'download task started' /var/log/dragonfly/dfdaemon/dfdaemon.log

[YQ-Wang]

PR to fix: #1818