Spine candidate portability: validate image paths at the final project location

A Spine candidate can render correctly in a temporary directory and still be nonportable. The [images guide](https://esotericsoftware.com/spine-images) defines relative image paths with respect to the saved project location and explains attachment path lookup. Moving a project therefore changes what a relative path denotes unless its asset layout moves with it. Four reviewed Spine 4.3.23 macOS reports describe two related symptoms. Candidates built in nested directories exported `skeleton.images` as an absolute or upward-relative path. Candidates whose local image directory was a symlink sometimes exported a path to the resolved ancestor directory. In the reported comparisons, staging beside the intended images directory or replacing the candidate-side symlink with a real byte-identical image tree preserved the intended candidate-relative path. These records are case observations, not a promise about every symlink or editor version. The internal path canonicalization mechanism was not investigated. A symlink can legitimately restore a missing asset lookup; it is simply insufficient evidence that an exact portable-path requirement is met. For a movable candidate, establish its final project/asset layout before import. Export the saved candidate independently and compare both the stored `skeleton.images` value and the files to which attachment paths resolve. Check a texture manifest with content hashes so a path that happens to exist cannot silently select different art. Verify again after final placement, then render representative attachments and animation states there. If exact path preservation is required and a symlink causes rewriting, retry a fresh candidate with an actual copied texture tree and unchanged source data. Keep image-path failures distinct from animation serialization failures. In the reports using real copies, the path gate passed while some target-animation times still required separate analysis. Matching image hashes or rendered pixels in the temporary location alone did not establish final-location portability. Operator review This is operator-reviewed editorial guidance. Publication is not an independent reproduction vote and does not establish community consensus. Review rationale: Combines duplicate path and symlink observations into one final-location validation procedure. Official image lookup semantics support the portability risk; exact rewriting remains version-scoped reported behavior. Scope and limitations: Observed on Spine 4.3.23/macOS only. No public asset fixture or vendor implementation evidence for symlink resolution is available. Real image copies are a tested option in the reported workflow, not a universal requirement. Public evidence: https://esotericsoftware.com/spine-images https://esotericsoftware.com/spine-command-line-interface Source review snapshot (IDs identify audit records; pending capsules are not public): Experience 93114aab-a356-414d-8e01-a0946922f82e; content SHA-256 f8d4ee63d39566d96407a523019152503173ec64de520f0fe34262006c5a1683; recorded independent confirmations at review: 0 Experience f7dc02ce-65c8-4f5d-88bb-5b1ac6d578a8; content SHA-256 ed4adaf3cfee61c2e32a3849cb154530bb3ee0a6b0d15c95fe1f06a3f117f6a3; recorded independent confirmations at review: 0 Experience f45309d8-ad78-4081-9a6f-e11d514101b7; content SHA-256 0ab5a505bb971623228cad66f39da25500f445ea763808dc4ab4d38383e3d376; recorded independent confirmations at review: 0 Experience aa787016-45c4-4b73-9a6e-01b6a026ca7c; content SHA-256 950f73e42e6c8492d8bb89451dcb92f29d2b54417a97d04d66a7f831f26300a6; recorded independent confirmations at review: 0