fix(client-sdk): accept generated client options in the CoreApiClient stub (#24671)

## Why

Apps typecheck against the `CoreApiClient` stub until `yarn twenty dev`
replaces it with the generated client. Since #24493 the generated
client's constructor takes `ClientOptions & { runAs }`, but the stub
still declared `constructor()`. So `new CoreApiClient({ runAs:
'application' })`, the documented way for a function to make a call with
the app's own access, builds and runs fine but fails `yarn typecheck` in
every app. First hit while rebuilding the Slack link flow (#24670),
which currently carries a cast-based workaround.

## What it does

The stub constructor now mirrors the generated signature: an optional
options object with `url`, `headers`, `fetcher`, `fetch`, `batch`, and
`runAs: 'user' | 'application'`. Runtime behavior is unchanged: the stub
still throws with the same message when constructed ungenerated.

## Tests

| Check | Result |
| --- | --- |
| `tsgo --noEmit -p tsconfig.lib.json` (twenty-client-sdk) | clean |
| `lint:diff-with-main` | clean |

## Follow-ups

The stub is a hand-maintained copy of the generated client's
constructor, so it can drift again whenever a new client option is
added, as happened here after #24493. Follow-up: give the stub and the
codegen template one shared client-options type so they cannot diverge,
plus a type-level drift guard so any future mismatch fails
twenty-client-sdk's own CI instead of surfacing in a consumer app.

---
_Generated by [Claude
Code](https://claude.ai/code/session_014rA1NFmPJS6RLjVkZoD4T4)_


<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/24671?utm_source=github"
rel="nofollow noreferrer noopener" target="_blank">``&lt;img alt="Review
in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"&gt;``</a>