Remove the v1 TypeORM workspace ORM (#24718)

## What

Removes the v1 TypeORM workspace ORM now that ORM v2 is the only
read/write path for workspace data. The v1 `GlobalWorkspaceDataSource` /
`WorkspaceEntityManager` / `WorkspaceRepository` / query-builders /
entity-schema factories were kept alive only through the ORM manager's
return-type cast and a handful of consumers; this deletes them after
migrating those consumers.

## How

**Manager return type (main effort).**
`GlobalWorkspaceOrmManager.getRepository()` and the transaction-scope
`getRepository()` now return `WorkspaceRepositoryV2` directly instead of
casting the v2 repo to the v1 `WorkspaceRepository`.
`WorkspaceRepositoryV2` is made generic
(`WorkspaceRepositoryV2<TEntity>`) so its read methods stay typed
against the entity, which preserves the existing typed call sites and,
instead of a fake full-TypeORM surface, exposes only the methods v2
actually implements. Fixing the resulting type errors surfaced the
genuine v1-API usages:

- dropped the `insert`/`update`/`updateMany`
`columnsToReturn`/queryRunner args that v2 already ignored at runtime,
- replaced `getManyAndCount()` with `getMany()` + `getCount()`,
- bound a join-condition parameter through `setParameter` (it was being
silently swallowed as the join options arg),
- converted an object-form `select` to the v2 `string[]` form and
dropped a v2-noop `loadEagerRelations`,
- retyped the person-email query-builder helper and a couple of
query-builder mocks to the v2 builder.

**Deletes.** `global-workspace-datasource(.service)`, the workspace
entity-manager, `workspace.repository` and its five query-builders, the
workspace query-runner, the entity-schema factories, and the now-dead
v1-only utils and duplicate-key error-handling chain.
`relation-nested-queries` is decoupled from the v1 select query-builder
(the live common-query-runner path only uses the connect-query runner).
The manager's `getGlobalWorkspaceDataSource*` accessors are removed, the
datasource module is trimmed, and `twenty-orm.module` is deleted (its
only providers were the factories, injected nowhere).

The no-op `WorkspaceORMEntityMetadatasCacheService` is deliberately kept
so committed upgrade commands and the migration runner can still
invalidate the `ORMEntityMetadatas` cache key.

## Notes

- API-visible behaviour is unchanged: every migrated call already ran
against v2 at runtime, so dropping the ignored v1-only arguments
preserves current behaviour.
- One pre-existing latent bug was found but left out of scope (flagged
separately): the company-restore path reads `domainNamePrimaryLinkUrl`
from an `updateMany` result, but v2 `updateMany` only returns `id`.

## Verification

- `tsgo --noEmit`: clean
- `oxlint --type-aware` and `oxfmt --check` on the diff: clean
- Touched unit specs pass; `server-integration-test` is the real
end-to-end coverage (record CRUD, calendar/messaging sync, upgrade
commands).


<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/24718?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->