fix: restore package-type Image branching (regression in v1.1.1)

[JamBalaya56562]

The durable-functions refactor (#65) removed the package-type branching
in run(), createFunction, and updateFunctionCode, so Image deployments
now fail unconditionally with:

Packaging code artifacts from
Failed to package artifacts: Code artifacts directory path must be provided

because packageCodeArtifacts() is called even when no
code-artifacts-dir is configured.

This restores the v1.1.0 behavior:

• run() skips packageCodeArtifacts when packageType === 'Image'
• createFunction sends Code: { ImageUri } and PackageType: 'Image',
  and omits Runtime / Handler / Layers for Image
• createFunction includes ImageConfig only for Image
• updateFunctionCode sends ImageUri instead of ZipFile for Image
• updateFunctionConfiguration omits Handler / Runtime / Layers for
  Image and includes ImageConfig only for Image
• hasConfigurationChanged uses the same gating
• the PackageType-change guard is restored
• durable-functions config from feat: add support for durable functions #65 is preserved unchanged

Adds a regression test that exercises the real createFunction and
updateFunctionCode with package-type: Image and asserts that ImageUri
is sent and that ZipFile / Runtime / Handler / Layers are not.

Fixes #70.

[JamBalaya56562]

@reedham-aws Could you review it?

[reedham-aws]

Thank you very much for raising this!

There is one thing I'm confused about, which is where this issue was introduced. Looking at #65, this code isn't deleted, but it was deleted in #39 (my own pr to add a linter action). I have no idea why this was changed in that PR because theoretically it was only linting. Do you know if this has been an issue since that was merged on 2025-08-20?

Would you mind explaining what lead you to the durable functions PR? Was it the version of the action that started failing?

[reedham-aws]

I don't think it makes sense to reference the issue number in the code because it's not clear at a glance what the issue is or what this test is doing from that name.

[JamBalaya56562]

Good point — agreed, the issue number doesn't convey what's being tested.
I've renamed it to Image package type wiring through createFunction and updateFunctionCode and dropped the // Regression tests for issue #70… comment above the describe block.
The PR description still links #70 for the historical context.

[JamBalaya56562]

Thank you very much for raising this!

There is one thing I'm confused about, which is where this issue was introduced. Looking at #65, this code isn't deleted, but it was deleted in #39 (my own pr to add a linter action). I have no idea why this was changed in that PR because theoretically it was only linting. Do you know if this has been an issue since that was merged on 2025-08-20?

Would you mind explaining what lead you to the durable functions PR? Was it the version of the action that started failing?

Thanks for digging into this — you're right.
I re-checked the diff of #39 via gh api and the package-type branching really was removed there (index.js: +159/−201, far more than a typical lint:fix).
#65 didn't touch this code path.

So yes: the bug has been on main since #39 merged on 2025-08-20, ~2 hours after v1.1.0 was tagged.
It just wasn't user-visible until v1.1.1 was published on 2026-04-29.

As for why I pointed at #65: I was working from the v1.1.1 release notes / changelog rather than the actual diff.
The reporter in #70 confirmed v1.1.0 worked and v1.1.1 didn't, so I narrowed it to the v1.1.0…v1.1.1 range, and #65 was the most prominent index.js change in that range (it's the headline feature in the v1.1.1 notes), so I assumed the regression came from there.
I should have run git log -p between the two tags instead of trusting the release-note shape.
Sorry for the misattribution — I'll update the PR title/body to point at #39 if that's helpful.