refactor(api): split api/workflow.py so the last workflow creation path can record its owner (#17014 AC1 exception) #17655

api/workflow.py is at its shrink-only ceiling, so the last workflow creation path cannot record an owner

#17014 gave every workflow creation path an owner_id, with one stated exception:

autobot-backend/api/workflow.py:292, in _execute_complex_workflow:

    workflow_id = await manager.create_workflow_from_chat_request(workflow_request.user_message, session_id)

Recording an owner here needs three lines that cannot be avoided: a current_user parameter
on execute_workflow, an owner_id parameter on _execute_complex_workflow, and the
caller_id import. The file is 1027 lines and carries a recorded ceiling of 1027 in both
repo_tests/python_file_size_ratchet_baseline.py and
scripts/python_file_size_known_large.py. The ratchet is bidirectional — above the ceiling
fails, below it fails until the ceiling is lowered — and CLAUDE.md says to split rather than
raise. So the change was reverted rather than landed half-done or landed by growing a
ratcheted file.

This is not an open authorisation hole

Worth stating plainly so it is not read as a shipped vulnerability:

• execute_workflow is admin-only (Depends(check_admin_permission)).
• Under workflows: owner_id is never recorded, so workflow control cannot be scoped to its owner (REST control is open to any signed-in user) #17014 a workflow with no recorded owner is admin-only to control — an absent owner
  fails closed, it does not mean "anyone may".

So the only live consequence is that an admin-created workflow from this route resolves no
user secrets, because #17014 also removed the session_id fallback that previously stood in
for an owner. Previously it resolved secrets under an opaque session string, which found
nothing useful either.

Acceptance criteria

• api/workflow.py is split so no resulting file exceeds MAX_LINES (600), and its
  entries are removed from both the ratchet baseline and the known-large list rather than
  re-pinned at a lower number. Split along the existing seams — the admin-only
  /api/workflow/* surface versus the execution helpers — not by line count.
• _execute_complex_workflow records the authenticated caller as owner_id, matching the
  other five creation paths, using caller_id from
  services/workflow_automation/workflow_ownership.py so the recorded identity is the one
  the ownership checks compare against.
• A test asserts a workflow created through this route carries the caller as its owner,
  mirroring test_create_workflow_records_the_caller_as_owner in
  workflow_ownership_17014_test.py.
• workflows: owner_id is never recorded, so workflow control cannot be scoped to its owner (REST control is open to any signed-in user) #17014's AC1 can then be ticked with this path included; until then its exception stands.

Related

#17014 (records the exception), #2304