feat:[SG-43421] Migrate FlowAM publish hooks phase1 & 2

[chenm1adsk]

Summary

Migrates Flow AM publish hooks from tk-config-flowam POC into upstream tk-multi-publish2 in two phases, eliminating the tk-framework-flowam dependency.

Phase 1 - Lift-and-shift the hook chain into hooks/flowam/, then refactored into a single self-contained DccFlowPublishPlugin + Desktop counterpart, each subclassing publish_file.py directly.

Phase 2 - Embed Flow AM logic directly into the stock collector.py, pre_publish.py, and publish_file.py hooks, gated on ctx.flow_project_id at runtime. Adds a self-contained python/tk_multi_publish2/flowam/ package for publish orchestration.

Also includes single_file_mode for the publisher dialog (SG-43419), used when republishing an existing Flow AM generic asset from the Desktop Loader.

Note: Non-Flow-AM projects are unaffected - all Flow AM branches are gated on ctx.flow_project_id and engine.flow_host.

Dependencies

• tk-core: SG-43461 SG-43644 Migrate host base and other support tk-core#1108
• tk-multi-loader2: SG-43456 [Phases 1-2] Enable FlowAM integration tk-multi-loader2#137
• tk-houdini: SG-43461 SG-43644 Migrate Flow host support for Houdini tk-houdini#103
• tk-nuke: SG-43461 SG-43644 Migrate Flow host support for Nuke tk-nuke#134
• tk-desktop: SG-43461 SG-43644 Migrate Flow host support for Desktop engine tk-desktop#224

Config requirements

The stock hooks now handle Flow AM natively - no hook chain overrides needed for DCC environments.

env/includes/desktop/project.yml:

 tk-multi-publish2:
   publish_plugins:
   - name: Publish to Flow AM
     hook: "{self}/publish_file.py"
     settings: {}

env/includes/maya/apps.yml (same for houdini, nuke):

 maya.apps.tk-multi-publish2:
   publish_plugins:
   - name: Publish to Flow AM
     hook: "{self}/publish_file.py:{engine}/tk-multi-publish2/basic/publish_session.py"
     settings: {}
   - name: Publish Alembic Derivative
     hook: "{self}/publish_file.py:{engine}/tk-multi-publish2/basic/publish_session.py:{self}/flowam/publish_alembic_derivative.py"
     settings: {}

Test plan

• Publish on DCC with FlowAM config
• Publish on Desktop with Flow AM config
• Non-Flow-AM project - publishes normally with no regression

TODO

• Remove tk_core_ref from azure-pipelines.yml after SG-43461 SG-43644 Migrate host base and other support tk-core#1108 is merged

[codecov]

Codecov Report

❌ Patch coverage is 39.28571% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 40.09%. Comparing base (0c85314) to head (945de1c).

Files with missing lines	Patch %	Lines
python/tk_multi_publish2/dialog.py	0.00%	14 Missing ⚠️
python/tk_multi_publish2/__init__.py	60.00%	2 Missing ⚠️
app.py	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #217      +/-   ##
==========================================
- Coverage   41.21%   40.09%   -1.13%     
==========================================
  Files          62       60       -2     
  Lines        5054     4617     -437     
==========================================
- Hits         2083     1851     -232     
+ Misses       2971     2766     -205     

Flag	Coverage Δ
Linux	40.09% <39.28%> (-1.13%)	⬇️
Python-3.10	40.09% <39.28%> (-1.13%)	⬇️
Python-3.11	40.09% <39.28%> (-1.13%)	⬇️
Python-3.13	40.09% <39.28%> (-1.13%)	⬇️
Python-3.9	40.09% <39.28%> (-1.13%)	⬇️
Windows	40.09% <39.28%> (-1.13%)	⬇️
macOS	40.09% <39.28%> (-1.13%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[carlos-villavicencio-adsk]

Looks good for a first phase. I'm not sure if this is considered to change and merge it into the existing hook workflow once the dependencies (framework, etc) are migrated.

[chenm1adsk]

Looks good for a first phase. I'm not sure if this is considered to change and merge it into the existing hook workflow once the dependencies (framework, etc) are migrated.

My understanding was that the initial plan was to first get the hook in place, and then, after the framework dependency migration, design it so the hooks are picked up automatically when sg_flow_am_id and the draft ID (for publisher) are available in the context.
For the loader, the trigger condition might be slightly different, but I thought that was the original idea as well.
Please let me know if I’m misunderstanding anything or if there are any gaps in my understanding.
cc: @yungsiow