feat: extend Canvas Candy support to full class catalogue

[LeslieOA]

Summary

Now that the baseline class set is in place (ported into src/renderer/extensions/cssclasses.ts and callouts.ts during the initial scaffold; conformance tests tracked in #16), extend support to the broader Canvas Candy class set that the baseline doesn't cover. These are classes used in published Canvas Candy demos but not yet implemented — they need a research pass + design work to translate into renderer primitives.

Scope — classes to research and decide on

From the upstream TfTHacker/obsidian-canvas-candy plugin and community examples, candidates include (non-exhaustive):

• cc-postit / cc-card-postit — post-it visual (slight tilt + warm fill + offset shadow)
• cc-card-pinned — pin icon overlay
• cc-card-faded — reduced opacity / desaturation
• cc-text-bold and similar text-style modifiers
• Per-card color overrides (cc-color-1 … cc-color-N, or named-palette equivalents)
• Any other documented but unimplemented classes

Approach

1. Catalog pass — produce a complete inventory from the upstream plugin source + Canvas Candy gallery / docs. Output: a checklist with screenshots or visual references for each class.
2. Categorise each class:
   • Direct port — one-to-one mapping to a new renderProp (simple visual treatments)
   • New render primitive — requires renderer work (e.g., icon overlay for cc-card-pinned)
   • Skip — not feasible without an Obsidian theme runtime, or low-utility
3. Implement in priority order — visual-only classes are quick wins; classes requiring new primitives need their own design

Note

This is a tracker. Sub-tasks should be split out as the catalog firms up — don't pre-create sub-issues until step 1 is complete.

Agent-ready prompt

Catalog the Canvas Candy class set that goes beyond the baseline implementation. Read the upstream plugin at github.com/TfTHacker/obsidian-canvas-candy and its README/gallery. For each class not in the baseline, capture: (a) visual effect, (b) Obsidian implementation mechanism, (c) feasibility category — direct port / new primitive / skip. Output the catalog as a comment on this issue, then propose a sub-issue split. Don't write implementation code yet — that comes after the catalog is reviewed.