docs(specs): update auth-capture evm spec

[avidreder]

Description

Updates the auth-capture specs to make server-requested operations explicit:

• Replace extra.autoCapture operation selection with payload.type for authorize, charge, capture, void, and refund.
• Document the EVM mapping from each operation type to its AuthCaptureEscrow call.
• Add compact per-operation payload field requirements, optional serverAuthorization, extra.serverAuthorizationRequired, smart contract operator guidance, and server self-facilitation guidance.

Tests

• ReadLints diagnostics for touched markdown files: no linter errors.
• Not run: full language test suites; docs/spec-only change.

Checklist

• I have formatted and linted my code
• All new and existing tests pass
• My commits are signed (required for merge) -- you may need to rebase if you initially pushed unsigned commits
• I added a changelog fragment for user-facing changes (docs-only changes can skip)

[vercel]

@avidreder is attempting to deploy a commit to the Coinbase Team on Vercel.

A member of the Team first needs to authorize it.

[A1igator]

@avidreder Not sure what the plan with this PR is since it's a draft but this is not the best design. Server interacting with the escrow should be coded in the captureAuthorizer smart contract itself and we already do so with our contracts.

You're adding a very specific style of captureAuthorizer (facilitator EOA) helpers, which a) as I mentioned before should be discouraged even if supported: #1425 (comment) and b) will be very confusing for anyone using the smart contract captureAuthorizer because the new functions added in the spec would be broken and c) Not really sure how this is supposed to work merchant developer experience wise. Would they change their endpoint and hit the facilitator directly? right now schemes are set and stay at each endpoint and clients hit them.

If there is any demand for this kind of structure anyways despite my objections above and how the same functionality can be done via captureAuthorizer smart contracts more trustlessly, I'd at least recommend an optional companion doc not in the main spec itself to not pollute it for smart contract captureAuthorizer use cases which is where we see most demand.

Would love to know @fabrice-cheng's thoughts as well.