Document idempotency conflicts and sync field detection, bulk metadata, and parent teams

[jspaetzel]

Summary

• Document that a POST or PUT can return 409 when an Idempotency-Key header is reused with different parameters, or while the original request is still in progress.
• Add an optional Idempotency-Key header and an Idempotent-Replayed response header to authenticated POST and PUT operations in the API reference.
• Mark both with x-hideOn: sdk so OpenAPI Generator does not add an idempotency argument to every SDK method. Callers pass the header through the existing per-call headers or options argument.
• Sync the spec with current Sign source:
  • Document field detection accepts application/json as well as multipart form data, and no longer requires exactly one of file or file_url.
  • Bulk send with template metadata uses maxProperties: 10, and each bulk signer can include metadata.
  • Team create and the team response include parent_team_id. The team response also includes team_id.
  • The raw spec includes a closed-beta account API key endpoint. It stays hidden from the published docs and SDK specs.

Test plan

• Confirm OpenApi::DESCRIPTION and the spec info.description remain Dropbox Sign v3 API.
• Confirm ErrorCatalog::conflict::SUMMARY is unchanged and the conflict cause and remediation still describe key reuse.
• Confirm openapi.yaml and openapi-fern.yaml list Idempotency-Key and Idempotent-Replayed on a POST, and a GET does not.
• Confirm openapi-sdk.yaml and the SDK sources do not add an idempotency parameter to method signatures.
• Confirm document field detection documents both JSON and multipart request bodies.
• Confirm bulk-send metadata and per-signer metadata are described, and team create and team response include parent_team_id.
• Confirm the account API key endpoint is absent from openapi.yaml, openapi-fern.yaml, and openapi-sdk.yaml.