Inconsistencies in Workflow model

We have a StoredWorkflow class and a Workflow class. StoredWorkflows belong to a user, have names, tags and are displayed in the workflow menu.
StoredWorkflows and Workflows can be addressed by an encoded id or a uuid.
StoredWorkflows have one or more associated Workflow instances (which contain the actual WorkflowSteps).

When you export a workflow you usually export the latest Workflow attached to a StoredWorkflow (unless a version is specified). A parent Subworkflow can include Workflow instances.

This is all fine, but when you export a workflow to another instance, the UUID is maintained, which is nice in principle, but the UUID is not necessarily unique anymore (plus you can of course manipulate the UUID ...). So if 2 users import a workflow with the same UUID the first (or last? didin't verify) users workflow will be returned. If one of them is not public you may be blocked from accessing your own workflow. We can probably address this by taking into account the requesting user (if we have one), but this is a but unfortunate if you want to address workflows on multiple servers using a common id.

Another problem are exported Subworkflows that contain workflow steps. If you import them, the included workflow gets imported as well, but there will be no associated StoredWorkflow. This means the current `api/workflows/` endpoints will simply not find the workflow, even when passing `instance=true` as a parameter. We can get an associated StoredWorkflow if we walk back the `WorkflowSteps` table until we find a parent workflow that includes this workflow, but this may be recursive (workflow in a workflow in a worflow ...) and serializing the parent workflow is likely not the correct thing to do.

I am thinking that a good course of action would be to add a `StoredWorkflow` instance for every `Workflow`. `Workflow` instances imported as part of a subworkflow could set a `hidden` flag if we want to keep them hidden in the user interface as we do now. Adding a visible `StoredWorkflow` via a database migration could possibly cause confusion (`why are there a bunch of workflow here now?`), but this could be another option.

Start by reading the StoredWorkflow and Workflow models and the api/workflows/ endpoints. Trace how imported subworkflows and WorkflowSteps are represented, including lookup by encoded id or UUID and the instance=true path. Define the intended ownership, visibility, uniqueness, and migration behavior before choosing an implementation.

Written by the indexing model from the issue text.