feat: add the 2D and tilemap skills

[ziyiunity]

Second batch of the Unity skill migration, grouped by domain: 2D rendering and tilemaps. Six skills, 63 files, on top of the UI batch that landed in #41.

Skill	Files	What it covers
2d-pixel-perfect	6	Pipeline detection, filter modes, camera setup, reference resolution
manage-sprite-atlas	45	Prebuild atlas pipeline, master and variant atlases, packing and platform settings
sprite-segment-3x3grid	2	Analyzes a sprite into a 3×3 color-match pattern
tilemap-palette-create	2	Tile Palette assets for rectangular, hexagonal, isometric grids
tilemap-ruletile-createempty	3	Blank RuleTile, HexagonalRuleTile, IsometricRuleTile
tilemap-ruletile-createfromsegment	4	RuleTile tiling rules from terrain sprites, consuming sprite-segment-3x3grid output

What was adapted

The name: key was added to every skill, as this repo's convention requires, matching the folder in each case. Beyond that, the files landed byte-identical to the version these skills ship with elsewhere. Three of them have since changed on this branch; see Later fixes on this branch below.

Checked before pushing: no author: in any frontmatter, all 145 relative references/ and resources/ paths resolve to real files, every description is within the 1,536-character listing cap, and no skill references another as a slash command (they name each other instead, so the references work on hosts that don't expose skills as commands).

Later fixes on this branch

The link check above originally passed only because it looked at SKILL.md. Every link from manage-sprite-atlas/references/*.md into resources/ was broken: 38 of them, written as resources/foo.cs, which resolves relative to references/ and so pointed at a path that does not exist. One also had a typo (handelatebinding.cs). Combined with SKILL.md not linking the resources at all, this skill shipped 38 working C# files that could not be opened from anywhere. All of them now use ../resources/, and SKILL.md carries a path-to-files table at the top of its required-checks section so the resources get read before code is written.

manage-sprite-atlas: the SpritePacker mode step is now verifiable. It said "ALWAYS enable Sprite Packer mode in Project Settings" and stopped there, with no API and no verification. That step decides whether the atlas is real: Disabled is the zero value of SpritePackerMode, so any project nobody has configured carries it, and an atlas created while it is Disabled still imports, still looks finished, and can never pack. It now points at resources/enablespritepacking.cs for the call and requires reading the setting back and reporting the value.

Two tilemap descriptions were tightened, both observed misfires. tilemap-ruletile-createempty fired even when the user had provided sprites, despite its description already saying not to, so the negative is now absolute and routes to tilemap-ruletile-createfromsegment by name. tilemap-ruletile-createfromsegment matched nothing for "set my sprites up to auto-tile when I paint", because the description was written from the converter's point of view and never contained the word autotile, so it now leads with the user-facing phrasing.

One thing worth flagging before merge

Two of these skills describe creating an asset through an Editor-only API, and it is not obvious how an agent completes that step outside the Editor.

tilemap-palette-create instructs the agent to use GridPaletteUtility.CreateNewPalette, and ships scripts/CreatePaletteTemplate.cs, a public static class with no [MenuItem] and no entry point. An agent can write that file to disk, but nothing invokes it. For contrast, tilemap-ruletile-createfromsegment/RuleTileGenerator.cs in this same batch does carry a [MenuItem].

tilemap-ruletile-createempty points at resources/ruletile.md, which documents the rule patterns (the . . . / . * . neighbor tables) rather than the serialized asset format, so the step that actually writes the .asset is undefined.

These skills came from an environment that had an Editor execution channel, so the gap is a property of the porting context, not something introduced here. I've deliberately left the content unmodified rather than guess at a fix. The owning team should decide whether to add an entry point, document the asset format, or scope the skills differently. Happy to split either skill out of this PR if you'd rather it land separately.

[ChuanXin-Unity]

The Tilemap skills are editor-specific, so I believe it is fine if they make use of editor apis. Let me know if this is not the case, thanks!

[venkify]

LGTM. Thanks.