Refactor Client Class to Follow [finData, request] OPRF Convention

## Description
The current implementation of the `Client` class is designed to handle a single request at a time. This design can be surprising/confusing and does not align with the convention used in the OPRF setup, which returns a tuple `[finData, request]`.

## Proposed Solution

Two possible ways to approach this refactoring:

1. Rename `Client` to `TokenRequestContext` to better convey the per-request state and update its methods accordingly.
2. Modify the `createTokenRequest` method to return a tuple `[finData, request]` instead of a single `TokenRequest` object.

It's proposed to refactor the `Client` class to adhere to the OPRF convention.

```typescript
export class TokenRequestContext {
private finData?: {
pkIssuer: CryptoKey;
tokenInput: Uint8Array;
authInput: AuthenticatorInput;
inv: Uint8Array;
};

async createRequest(
tokChl: TokenChallenge,
issuerPublicKey: Uint8Array,
): Promise {
```

or

```typescript
interface Client2State {
authInput: AuthenticatorInput;
finData: FinalizeData;
}

export class Client2 {
vClient: Client;

constructor(private issuerPublicKey: Uint8Array) {
this.vClient = MODE.makeClient(issuerPublicKey);
}

async createTokenRequest(
tokChl: TokenChallenge,
): Promise<[finData: Client2State, request: TokenRequest2]> {
```

Start by locating the Client class, its createTokenRequest method, and the existing OPRF setup that returns [finData, request]. Compare the proposed TokenRequestContext rename with the tuple-returning alternative; done means one consistent per-request API is selected and the affected methods and callers follow it.

Written by the indexing model from the issue text.