[bug] Data table names collide across workspaces: the same name cannot be created in two workspaces

> *This was generated by AI during triage.*

## Summary

A data table cannot be created with a name that already exists in **another workspace**. Workspace B's
`orders` collides with workspace A's `orders`, even though each workspace sees only its own tables.

## Steps to reproduce

1. In workspace A, create a data table named `orders`.
2. Switch to workspace B (same environment) and create a data table named `orders`.
3. Creation fails. The underlying SQL error is "relation `dt__orders` already exists".

**Expected:** a data table name only has to be unique within its workspace (and environment).

## Root cause

A data table's identity is global, keyed on `(environment, name)`. The workspace is attached afterwards
through the `workspace_data_table` link table, and nothing that names or finds a table uses it.

- **Physical table name** is `dt__`, with no workspace in it, so the second
`CREATE TABLE` collides.
- **Registry row:** `data_table.name` is looked up globally (`DataTableRepository.findByName`) and the
schema enforces a global unique name. Even if the physical table were created, registration would find
and reuse the other workspace's row.
- **Every lookup is by base name:** `DataTableService` (`getIdByBaseName`, `listTables(environmentId)`),
`DataTableRowService` via `DataTableRef(baseName, environmentId)`, `DataTableWebhookService`,
`DataTableTagService.getTagsByTableName`, `DataTableReferenceResolver`, the AI data-table tool callbacks,
and the public data table REST API.

When the data table moved from automation to platform, `data_table.workspace_id` was replaced by the link
table. That fixed *visibility* (`WorkspaceDataTableFacade.listTables` filters by workspace) but not
*identity*.

## Related gap: the Data Table component ignores workspaces

The Data Table component's table picker lists **every** development-environment table regardless of
workspace. Its actions and triggers address a table by `baseName` + environment only, and
`ActionContext`/`TriggerContext` carry no workspace. So a workflow in workspace B can already select, read
and write workspace A's tables.

## Proposed direction (agreed in discussion)

- Name the physical table by the registry id: `dt__`. The `data_table` row stays
one per table (not per environment), so its development/staging/production copies share the id. A table
rename then only updates the row, the Postgres 63-byte identifier limit and name parsing stop mattering,
and the LIKE-pattern "does any environment still have this table" check can be dropped.
- Enforce "name unique per workspace" instead of a global unique name, and remove the global constraint.
- Address tables by id through `DataTableService` / `DataTableRowService` / webhooks / tags.
- Add a migration that renames each existing `dt__` table to `dt__` (Postgres and H2).
- Data Table component: resolve a table within the workflow's workspace, both in the editor (options,
output, dynamic properties) and at runtime (perform, webhook enable), and limit the picker to that
workspace.
- Build it on branch `0_732`, where naming is already centralized (`DataTableRef`, `PhysicalTableNaming`).
Doing it on `master` would conflict with that branch's data-table rewrite.

## Open design question

How the component gets its workspace. Editor calls (`WorkflowNodeOptionFacade`, `WorkflowNodeOutputFacade`,
`WorkflowNodeDynamicPropertiesFacade`) know the `workflowId` but don't pass it into the component context.
At runtime the context has `workflowId` / `jobPrincipalId`. A workflow's project gives the workspace, which
applies to AUTOMATION only. Embedded workflows have no workspace, so they need a defined fallback.

## Acceptance criteria

- [ ] Two workspaces can each create a data table with the same name in the same environment.
- [ ] Creating a duplicate name within one workspace fails with a readable error, not a raw SQL error.
- [ ] Rename, duplicate, drop, rows, CSV import/export, tags and webhooks each act only on the addressed
workspace's table.
- [ ] Existing tables and their rows survive the migration and keep working in workflows (Postgres and H2).
- [ ] The Data Table component's picker shows only the workflow's workspace tables, and actions/triggers
resolve names within that workspace.

Related: #5584, #5589