fix: Omit undefined optional fields from deserialised output (#1488)

## Summary

- Switches all deserialisers to the `...(value !== undefined && { key
})` spread-guard pattern so that optional fields absent from an API
response are omitted entirely rather than included as `undefined`
- Preserves explicit `null` values (e.g. `verificationToken: null`)
which are semantically meaningful
- Updates the `List` / `ListResponse` pagination cursor types from
`string` to `string | null` to match the values the API actually returns
- Updates `PaginationOptions` and `ListWarrantsOptions` to accept
`string | null` for `before`/`after`, so that pagination cursors from
API responses can be passed straight through without conversion
- Updates affected unit tests and snapshots accordingly

### Affected deserialisers

| File | Fields |
|------|--------|
| `session.serializer.ts` | `organizationId`, `impersonator` |
| `connection.serializer.ts` | `organizationId` |
| `authentication-event.serializer.ts` | `error` |
| `profile.serializer.ts` | `organizationId`, `firstName`, `lastName`,
`role`, `roles`, `groups`, `customAttributes`, `rawAttributes` |
| `directory-user.serializer.ts` | `role`, `roles` (both
`deserializeDirectoryUser` and `deserializeUpdatedEventDirectoryUser`) |
| `organization-domain.serializer.ts` | `verificationToken` |
| `vault-object.serializer.ts` | `value`, `listMetadata.after`,
`listMetadata.before` |

### Pagination cursor type changes

| Interface | Field | Before | After |
|-----------|-------|--------|-------|
| `List.listMetadata` | `before`, `after` | `string` | `string \| null`
|
| `ListResponse.list_metadata` | `before`, `after` | `string` | `string
\| null` |
| `PaginationOptions` | `before`, `after` | `string` | `string \| null`
|
| `ListWarrantsOptions` | `after` | `string` | `string \| null` |
| `SerializedListWarrantsOptions` | `after` | `string` | `string \|
null` |

## Discussion: Pagination cursor type (`string` vs `string | null`)

The WorkOS API documentation defines the `after` and `before` pagination
cursors as type `string`, yet the response examples clearly return
`null` when there is no further page:

```json
{
  "data": [...],
  "list_metadata": {
    "after": null,
    "before": "object_id_xxx"
  }
}
```

For example, see the [Vault list objects
reference](https://workos.com/docs/reference/vault/object/list).

This PR updates both the response types (`List`, `ListResponse`) and the
input types (`PaginationOptions`, `ListWarrantsOptions`) to `string |
null`. This means pagination cursors from API responses can be passed
directly back into list options without any coercion (e.g. `??
undefined`), making the API ergonomic and type-honest.

If the documentation is authoritative and the API should be returning
`undefined` (i.e. omitting the key) instead of `null`, then a
server-side change may be needed. Either way, the SDK types should match
the actual response shape, and the input types should accept whatever
the output types produce.

## Test plan

- [x] `npx tsc --noEmit` passes
- [x] All 590 tests pass (31 suites)
- [x] All 17 snapshots pass
- [x] Prettier and ESLint clean

---------

Co-authored-by: Garen J. Torikian <gjtorikian@users.noreply.github.com>