OK. that means to me:
- bring your own iris.cpf  (and your own license )
as I have done already in past in several cases.
And it means to have one repository for demo and another for distribution. 

Hi @Chip Gore !
extrapolating Vic's very valid comment:
- if you have to take the sour apple of migration, let it be the last time.
- why not install WSL2 and migrate into a Linux environment. Or even into a docker scenario

my private view: a good trigger to let the dead horse behind
[ I was told red Indians don't saddle a dead horse wink]

a few comments.
A mirrored DB get's an embedded timestamp that links it with its master.
the timestamp indicates when de-journaling must start.
there is a quite detailed description of how to add a Db to a MIRROR 

If HSSYS is a  SYSdb: it can't be mirrored
  

in DockerFile

USER  root
## add git
RUN apt update && apt-get -y install git

A little bit of cosmetics in your printf could make it JSON formatted.

 print(f'{{"subscript":{subscript},"value":"{value}"}}')

which should result in a nice conveniant JSON object

{
  "subscript":1,
  "value":"2.16.840.1.113883.3.86ISCInterSystems Corporation"
  }

try:

 Property alternateId As %String(%JSONNULL = 1);

  {
        "alternateId": null ,
        "benefitPlanId": "FLSN4444", 

If you get back large results sets that you use for further processing PyODBC will be better suited.
But for a small number of values, the overhead at both ends to service ODBC structures may not pay off
since both ends have to get their internal structure in to  ODBC and out of it.
I don't have measured the difference so this is just a guess:
- for the typical embedded SQL returning < 1..10 rows a MethodCall might be more efficient.
This doesn't prevent you from using and tuning an SQL SELECT isolated in IRIS environment. 
In any case, the transfer between PY and IRIS is the slowest piece.
The less data you transport the faster the action is completed.
And transport in blocks wins over isolated pieces in loops.