Refactor: Reduce parameter threading and layer depth in access token request chain

[stevenvegt]

Problem

The access token request call chain threads individual parameters through 4 layers:

API handler (auth/api/iam/api.go)
  → IAMClient.RequestRFC021AccessToken (auth/client/iam/interface.go / openid4vp.go)
    → Wallet.BuildSubmission (vcr/holder/interface.go / sql_wallet.go / memory_wallet.go)
      → presenter.buildSubmission (vcr/holder/presenter.go)

This causes two related problems:

1. Tramp data / parameter bloat

RequestRFC021AccessToken has 8 positional parameters. Parameters like credentialSelection are only consumed at the bottom layer (presenter) but must be threaded through every intermediate signature, mock, and test expectation. Adding or changing a parameter cascades changes through all layers — e.g. during #4122 review, a cosmetic change (nil → map[string]string{}) would have required updating 8+ mock expectations.

2. Layer depth

Each layer serves a purpose (HTTP boundary → OAuth orchestration → credential loading → VP building), but the intermediate layers act as pass-through for several parameters. This raises the question whether the current separation is the right abstraction, or whether some layers could be consolidated.

Proposed solution (needs refinement)

One option is to bundle request parameters into a struct:

type AccessTokenRequestParams struct {
    ClientID            string
    SubjectDID          string
    AuthServerURL       string
    Scopes              string
    UseDPoP             bool
    Credentials         []vc.VerifiableCredential
    CredentialSelection map[string]string
}

This would reduce signature bloat and make the pass-through layers transparent to new fields. However, it doesn't address the layer depth question — consolidating layers or restructuring responsibilities might be the better solution. This needs further discussion.

Context

Discovered during review of #4122 / #4090.

[reinkrul]

Yes and no. This would be the domain of the first 2 layers, then you'd enter the VP domain in which you don't want a AccessTokenRequestParams.