[3e] Improve README: quick-start, API reference, migration notes, architecture diagram

[kalwalt]

Summary

Improve README with quick-start guide, API reference, migration notes, architecture diagram, and fix package.json contributors

Environment

• Product/Service: FeatureSET-Display — Documentation
• Files: README.md, package.json

Problem Description

The README lacks the information needed for a new developer to install, build, and use the library. There is no API reference, no migration guide for consumers upgrading from the legacy arfset.api.js to the ES6 ARFset class, and no architecture overview explaining the C++ ↔ wasm ↔ JS boundary. Additionally, package.json's contributors field contains a single empty string, which is incorrect.

Expected Behavior

• README has a quick-start section covering install, build, and running the example.
• A public API reference table lists all public methods, their parameters, return types, and emitted events.
• A migration guide helps users move from the legacy global-ARfset API (arfset.min.js) to the ES6 ARFset class.
• An architecture diagram (or clear prose) describes the C++ ↔ wasm ↔ JS data flow.
• package.json contributors contains correct entries.

Actual Behavior

README is sparse. No quick-start, no API reference, no migration notes, no architecture overview. package.json has an empty-string contributor entry.

Tasks

• Write a quick-start section in README.md: install, build, run example
• Write an API reference table: public methods, parameters, return values, emitted events
• Write migration notes from legacy arfset.api.js / window.ARFset to the ES6 ARFset class (ties into issue 2d)
• Add an architecture diagram (Mermaid or image) illustrating the C++ ↔ wasm ↔ JS boundary
• Fix package.json contributors — remove the empty-string entry and add correct contributor info

Impact

Low — Documentation only; no code change. Improves discoverability and reduces friction for new contributors and consumers.

Additional Context

Migration notes (quick-start and API reference) are best written after issue 2d (legacy API deletion) lands, so they document the final state rather than a transitional state. The architecture diagram is independent and can be added at any time. The package.json fix is a one-liner and should be done immediately.