I believe we have a solution. For those interested in the solution and also all the tests we did, here you go.
Process Update: We got to a point where we could permanently convert the SQL Server Service Accounts to GMSA accounts. Then it was time to see what we could do with SSIS now that the Service Accounts were changed. Prior to doing the tests below, the same SSIS code, which was created in Visual Studio SSDT, was uploaded into SQL Server 2 ways:
 with the old style MSDB database (by importing the package into Integrated Services server in the Stored Packages folder) and also
 into the new SSIS Catalog.
To repeat the goal: my business need is to have t-sql code that I can put into a stored procedure which will in turn run the SSIS code/package/project. The stored procedure will be called by a button on the front end which a user runs. So, the user needs to be able to run the stored procedure from the front-end application. However, I recognize that lots of people get this error (about the SSIS job not being able to access a file server) and most people do not need a user to run the SSIS code. They just need the SSIS code to run in a *scheduled* Agent job. Hence, I did all the tests listed below to help this community get a sense of what happens with various scenarios beyond just what my agency needs.
In the following tests, I did all the tests (except the last one) as myself/my account since:
....1) the tests were failing on me before we changed the SQL Server Service Accounts and
....2) if it doesn't work for me, it certainly isn't going to work for my user, and
....3) some of these options are helpful for future problem solving, and I wanted to know which options would be available in the future for my own developer needs.
The big question is, can SSIS access our file server? I tried to answer that question with these tests running as myself:
a) Object Explorer MSDB/Stored Package/MSDB (right click and "Run Package") >>> FAILED with: "Error, to run SSIS package outside of SQL Server Data Tools, you must install Standard Edition of Integrated Services or higher." (this is not the permissions problem, but it means that I can't do this test.)
b) Object Explorer Catalog (right click on the package in SSMS in Object explorer in the Catalog area, and choose "Execute") >>> FAILED (failed with being unable to access the file server / runs under my account / likely double hop problem)
c) Direct Agent, MSDB (right click on Agent job which runs SSIS package stored on MSDB, and choose "Start job at step") >>> SUCCEED
d) Direct Agent, Catalog (right click on Agent job which runs SSIS project stored on Catalog, and choose "Start job at step") >>> SUCCEED
e) Scheduled Agent job, MSDB >>> SUCCEED
f) Scheduled Agent job, Catalog >>> SUCCEED
g) Direct t-sql with sp_start_job (run in SSMS in query window: EXEC msdb.dbo.sp_start_job N'MyJobName' ) >>> SUCCEED (Works when the Agent job is running either the MSDB or the Catalog version of the code--ie, this test was repeating c) and d) from above, but running the job from Microsoft's built-in stored procedure which runs Agent jobs.)
h) Direct t-sql in SSMS query window which runs code** to run the Catalog project >>> FAILED (failed because it runs with my account and we have a double-hop problem)
i) Stored proc containing t-sql which runs Catalog project (ie, this is test "h", but put inside a stored procedure) >>> FAILED (Actually, I thought this test succeeded the first time and ran under the GMSA account, but every subsequent time I have run it, it runs as my account and fails. I may have made a mistake on what I thought I was doing the first time.)
j) Stored proc containing t-sql which runs sp_start_job (stored proc run in SSMS in query window - tried with both Catalog and MSDB jobs) >>> SUCCEED
Using sp_start_job requires that the user have special permissions to run that stored procedure. The easiest solution seemed to be to go with i). However, when I ran i) from a button on my front-end application, the Catalog job ran as myself and FAILED again. 🙁 So running the Catalog project directly via t-sql code does not appear to be an option for us.
BOTTOM LINE FOR MY BUSINESS NEED: Now that the SQL Server Service Accounts have been changed to GMSA accounts which have the permissions to access our file server: I can run the Catalog project with t-sql, but only if I run the project through an Agent job which in turn runs a stored procedure containing: sp_start_job. MSDB packages cannot be run directly through t-sql, but like the Catalog project, can be run successfully through t-sql and the built-in sp_start_job stored procedure.
THE BIG FINALE: I set up the required permissions for my user to run sp_start_job. I then set up the front-end application to run the stored procedure containing the sp_start_job code. It worked! The user can run the job on-demand and the SSIS project accesses our file server without problem.
NOTE: If someone else out there doesn't want to or can't change the SQL Server Service Accounts and using a proxy on an Agent job is an acceptable solution for your company, see an earlier post where I got the proxy on an Agent job to also work.
Interesting side note: MDSB scheduled agent job takes 7-8 seconds. The Catalog job takes 12 seconds. A few seconds does not matter to me for this job. I'm just reporting this interesting difference. The Catalog consistently takes longer.
** Nifty Tip: To generate the code which runs a Catalog project, you can right-click on the package in the SSMS Object Explorer. When you choose "Execute," you get a dialog box which contains a button near the top, sort of toward the left side which is labeled "Script". Click the little drop down arrow on the Script button and you will see a couple ways to ask SSMS to generate the correct t-sql code for you. 🙂