fix: Recompile spritesheet asset and thumbnail when source file is changed

[Acissathar]

PR Details

Modifying a sprite source image (e.g. a PNG) without also modifying the .sdsprite asset file did not trigger recompilation of the SpriteSheet asset or its thumbnail. If you were to add a new sprite to the spritesheet, the thumbnail and spritesheet would update, but removing the sprite would then revert it back to the old one. The workaround was to manually clear the obj/stride cache, but that's very tedious when you're making minor tweaks to a sprite.

The Stride hash is computed from files/content declared via GetInputFiles() but neither SpriteSheetCommand nor SpriteSheetThumbnailCommand overrode GetInputFiles(), so changes to source PNG files were invisible. The actual .sdsheet asset file itself hadn't changed, so it skipped recompilation.

SpriteSheetAssetCompiler.cs:
Added GetInputFiles() to SpriteSheetCommand:
• Packing disabled: Declares the intermediate compiled texture URLs as content dependencies. The prerequisite TextureConvertCommand already tracks the source PNG and re-runs when it changes; by depending on its output, SpriteSheetCommand detects the change transitively and also re-runs.
• Packing enabled: The SpriteSheetCommand loads source PNGs from disk directly, so source files are declared as File inputs directly.

SpriteSheetThumbnailCompiler.cs:
Added GetInputFiles() to SpriteSheetThumbnailCommand, which always reads the sprite source PNG paths from the SpriteSheetAsset parameters and declares them as File inputs. The base implementation's inputs are preserved via base.GetInputFiles().

Now if you make a change to the underlying source it recompile the spritesheet and the thumbnail, so you can immediately run the project and see the updated sprites without having to delete any files or folders.

Related Issue

#791

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My change requires a change to the documentation.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have built and run the editor to try this change out.