add: agent-agnostic image generation for non-Codex users

[nicoecheza]

What

Makes the two skills work with any agent that can run a Python script, not just Codex. Codex behavior is unchanged — built-in image_gen is still the recommended path on that host.

Why

The skills were Codex-only because they required built-in image_gen and view_image. Agents like Claude Code and Cursor have neither. This PR adds a thin CLI fallback so the same skills run unchanged on those hosts.

How

• scripts/image_gen.py — agent-agnostic image generation CLI.
  • Optional backend: Google Gemini 2.5 Flash Image.
  • Selectable via --backend or SPRITE_FORGE_BACKEND; model overridable via SPRITE_FORGE_MODEL.
  • Supports --reference <path> for image-edit / variation flows.
• scripts/view_image.py — optional metadata shim for hosts without a built-in view_image.
• Both SKILL.md files updated to describe the dual path (built-in tool on Codex, scripts/image_gen.py elsewhere) and the equivalent reference-handling guidance.
• README adds a Supported Agents matrix and per-agent install sections.
• Optional SDKs live in a new requirements-optional.txt so Codex users keep a minimal install.

Backwards compatibility

• requirements.txt unchanged.
• Existing Codex SKILL.md instructions (image_gen, view_image, $CODEX_HOME/generated_images/...) all still apply on Codex; the new instructions sit alongside them as the non-Codex branch.
• No changes to scripts/generate2dsprite.py, scripts/extract_prop_pack.py, or scripts/compose_layered_preview.py.

Testing

• scripts/image_gen.py --help and scripts/view_image.py <path> verified locally.
• OpenAI request layer verified end-to-end against the live API (auth, request shape, response parsing). Full image generation was blocked by a billing-hard-limit on the test key — happy to re-run with a maintainer-provided key, or you can verify on your end with any working OPENAI_API_KEY.
• Postprocess scripts and skill markdown logic are unchanged, so existing pipelines on Codex are unaffected.