KonceptDragGlyph renders no component-kind sigil — drag image and badge disagree

[knowledge-graphlet]

Sub-issue of #742 (one KonceptAppearance spec for the badge renderers), alongside #860–#865.

Gap

KonceptDragGlyph renders identicon + store-resolved name + inactive state. It does not render the component-kind sigil, so a pattern dragged anywhere in Komet arrives without its P, a semantic without its letter, a stamp without its pentagon — while the same component rendered as a KonceptBadge shows the sigil correctly. The drag image and the inline badge disagree about what the component is.

Reported from the pattern navigator → Claude compose drag: the dropped chips show the sigil, the drag image does not.

Why this belongs to #742

KonceptBadge.setKind is currently the sole owner of the rule — "a concept stays bare, every other kind gets its sigil"; KonceptKind.STAMP gets the StampSigil pentagon; every other kind gets its coloured letter glyph, with the accessible kind name on the tooltip as the non-colour affordance.

The drag glyph needs exactly that rule. Copying it would make a second place the mapping lives — and #742 exists precisely so the appearance is single-sourced across renderers. The drag glyph is effectively another renderer the spec should cover: it is a distinct rendering path (snapshotted at 1:1 into fixed integer geometry, deliberately not a laid-out control), but it must consume the same kind→sigil source, including colour, letter, pentagon, and the accessible name.

Scope

• One appearance source supplies the sigil; KonceptBadge and KonceptDragGlyph both consume it.
• The glyph keeps its pixel-exact contract: the sigil composites into the fixed integer geometry, no rescaling, no resampling.
• The glyph's single- and multi-drag variants (setDragView, setMultiDragView) both carry it. The nid-resolving overloads already have the kind available.

Acceptance

• Dragging a pattern shows a drag image bearing the pattern sigil; a semantic shows its letter; a stamp its pentagon; a concept stays bare.
• The sigil in the drag image matches the badge's for the same component — same letter, same colour.
• The glyph is still snapshotted 1:1 at fixed integer geometry (no blur).
• The kind→sigil mapping exists in exactly one place in the codebase.

Blocks

#882 — converting the navigator and search cells to the glyph path must land after this, or those drags gain a correct border and lose the sigil at the same time.