Decide on and scope migration: internal/workflowapi (hand-written) vs internal/workflow_client (generated) #5

Context

PR #1 introduced internal/workflow_client, a fully OpenAPI-generated
Workflow Studio client (~40 files, ~12k lines), used so far for exactly one
endpoint (job logs). The existing internal/workflowapi (hand-written, but
already documented in CLAUDE.md as kept in sync with openapi-user.yaml)
remains in place and is still used by every other Workflow Studio command;
its StreamJobLogs method is now dead code.

PR author's stated intent: generating the client is more efficient than
hand-writing it, and the hand-written one will be deleted "later."

Problem

Right now the repo has two structurally different ways to call the
Workflow Studio API (different config/response wrapper types, separate
auth-token plumbing in cmd/helpers.go's resolveContext/
ensureWorkflowAuth, different error-handling shapes, and generated model
filenames that leak the upstream internal service's package path —
git_sbercloud_tech_dsworks_services_pipeline_src_... — into a public
repo). "Later" isn't scoped to any tracked work, so there's no guarantee
the duplication gets resolved, and every new Workflow Studio command has to
pick a client with no documented rule for which one to use.

Ask

Decide explicitly:

• Migrate all of internal/workflowapi's callers to the generated client,
  delete the hand-written one, remove the leaked internal path from
  generated filenames (see .openapi-generator.yaml's structPrefix/
  naming options, or rename post-generation), and update CLAUDE.md's
  architecture section accordingly. This should land as its own PR, not be
  smuggled into per-endpoint feature work.
• Or, if generation isn't meant to fully replace the hand-written client
  yet, document in CLAUDE.md when to use which, so this isn't decided
  ad hoc per command.

Follow-up from PR #1 review/discussion.