Font Awesome name form of `tools.<tool>.icon` is silently ignored

[sidgaikwad]

Found while wiring the demo up to exercise custom tool icons (#40).

The README documents three accepted forms for features.imageEditor.tools.<tool>.icon:

a URL, raw <svg>…</svg> markup, or a Font Awesome name

tools: {
  crop: { icon: 'fa-crop-simple' },
  text: { icon: 'https://example.com/icons/text.svg' },
}

The raw <svg> form works. The Font Awesome name form is silently ignored.

Reproduction

Running the demo against the live CDN embed (1280x800, editor mounted, defaults otherwise):

features: { imageEditor: { tools: { crop: { enabled: true, icon: 'fa-crop-simple' } } } }

Then inspecting the rendered rail:

[...root.querySelectorAll('svg[data-icon]')].map(s => s.getAttribute('data-icon'))

icon value	result
'fa-crop-simple' — the README's own example	❌ rail still renders data-icon="crop" (the default)
'fa-star'	❌ rail still renders data-icon="crop"
'<svg …data-probe="custom">…</svg>'	✅ custom SVG rendered, text removed from the default icon set

No <img> tags are emitted either, so it is not falling back to a URL interpretation.

There is no console warning — the option is accepted and silently does nothing, which is the worst failure mode for a config value.

Notes

• Both names are real Font Awesome icons, so this isn't a bad-name problem — and fa-crop-simple is the exact string in the README.
• The bare-crop default icons the editor ships are Font Awesome (data-prefix="fal"), so the icon set is present; only the consumer-supplied name path seems not to resolve.
• I did not test the URL form.

Either the name form is broken in the editor bundle, or the README documents a form that was never implemented — worth confirming which before the docs are corrected.

I've used the working raw-<svg> form in the demo PR for #40 rather than shipping an example that does nothing.