docs(duckdb): add S3-compatible endpoint secret example

[goanpeca]

Description

The DuckDB connection's secrets option passes every field straight through to CREATE OR REPLACE SECRET, so DuckDB's endpoint and url_style S3 secret parameters already work today without any code change. The two existing examples only show the Amazon S3 defaults, so nothing on the page tells users that pointing an s3 secret at a different S3 host is supported. The parameter list is only reachable via the DuckDB link at the bottom of the section.

This adds a third short example under "Cloud service authentication", alongside the list-format and dictionary-format examples, showing an s3 secret with a custom endpoint (and a commented url_style for providers that need path-style addressing).

Docs only, no code changes.

Test Plan

• Built the docs with mkdocs build using docs/requirements.txt and confirmed the new tabbed section renders and appears in the page table of contents.
• Parsed the new YAML block with yaml.safe_load to confirm it is valid.
• Confirmed DuckDB accepts endpoint and url_style in the exact CREATE OR REPLACE SECRET (type 's3', ...) statement that BaseDuckDBConnectionConfig._cursor_init generates, so the documented fields are real rather than aspirational.

Checklist

• I have run make style and fixed any issues
• I have added tests for my changes (if applicable)
• All existing tests pass (make fast-test)
• My commits are signed off (git commit -s) per the DCO

[mday-io]

The AWS-only examples above don't make it obvious how to point at an S3-compatible provider; so, nice addition!

Two small, non-blocking thoughts:

1. Duplication: this repeats the full gateways → connection → catalogs → extensions → secrets boilerplate already shown twice above (List Format and Dictionary Format examples). Could this instead be a short note + a single endpoint: "..." line added to the existing List Format example, rather than a duplicate block? Would keep the doc DRYer while surfacing the same info.
2. Python tab: other subsections here pair the YAML tab with an equivalent Python config tab - was leaving it YAML-only here intentional (there's precedent in the Onelake filesystem example below), or worth adding for consistency?

Either way, LGTM as documentation content, just flagging for your call on scope.