IMHO it is currently not possible. According to docs, any pending jobs/workflows in the same concurrency group will get canceled.
I'm facing the same issue because I want to limit my workflows (started with workflow_dispatch) to run sequentially, one at a time, and as far as I've found, it is impossible.
Maybe some suggestion to GitHub to implement such a feature to limit running instances of workflow without canceling any pending runs, keep them pending until the currently running one finishes.

concurrency is for allowing your jobs to shortcut when, for example, you have lots of pushes that trigger workflow from a branch, but only care about the latest results, not the one in the middle... (say your workflow takes 10 minutes, and you push every 2 mins a set of small changes... without concurrency, you'll have a new set of actions triggered for each push. With concurrency, you can abort already running and/or queued jobs that would do the same thing on obsolete refs to not waste time on them, and getting to the final run you need much faster).

Now, the easiest way would be to combine those jobs in one large workflow, so you can setup the proper dependencies between each job, so they can run sequentially (using needs on each job). If you don't want to (need the workflows to be managed/approved by different groups or something for example, you can try to setup something like this:

Assuming the following structure: each workflow (say a through f) contains 3 jobs (1,2,3).
Update workflow b through f to be manually triggered (your workflow dispatch should already allow that)
Update workflow a with job 4, that needs completion of all 3 jobs
That job likely does some checks, and then triggers workflow b (providing the necessary parameters to the workflow itself as needed)
Update workflow b through e the same way, triggering the "next workflow" similarly.

Now, when the "original trigger" happens (whatever the event, user/push/pr/etc trigger), only the first workflow is started. this will create jobs 1 2 3 with the dependencies defined there. Once they are all complete, job 4 (which depends on all 3) is then run, which triggers the workblow-b. that then creates the jobs 1,2,3 from workflow b, etc...

There will be interesting corner cases to explore when you cancel things mid-way through (either through the concurrency and/or through the UI by hand). For example, if you have concurrency set, but the run is past the first workflow, you'll end up in a position where it won't be cancelled those workflow-b though f until the new workflow catches up in the chain and cancel the already in progress one. There is likely things you can do to cancel all the possible actions related to that branch/ref/whatever (or previously created jobs).