Fetching options for a `dynselect`/`dynmultiselect` input was inconsistent
between deployed scripts and deployed flows:
- scripts ran through `push_script_job_by_path_into_queue` — a `script` job
with the script's path, tag, lock and codebase resolution;
- flows ran their schema dyn-select code as an anonymous `preview` with no
path and no tag (always the language default), and reported access
failures as a raw `SqlErr: no rows`.
Deployed scripts are left exactly as they were (that path already handles
tag/lock/codebase/on-behalf-of correctly). The flow branch now:
- carries the flow path on the preview job,
- reads the flow's `tag` under RLS and routes the job to it (falling back to
the language default when unset), matching the script's worker group, and
- runs `check_tag_available_for_workspace` on that tag — the same gate a
normal flow run and the script path apply — so a caller who can read the
flow but is not allowed to use its (custom/scoped) worker tag is rejected
consistently.
The flow's tag read runs on every request, so it also serves as the
per-request access check, replacing the raw error with a clean
`NotAuthorized` / `NotFound`. Entrypoint-name validation now covers all
branches (it is interpolated into the generated wrapper). Inline is
unchanged: a `preview` with no path on the language default, blocked for
operators.
Fixes WIN-2118
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>