refactor: extract createNftDataSet into markerCreatorCore.{h,cpp} (decouple core from bindings)

[kalwalt]

Summary

Follow-up to #25. Today emscripten/markerCreator.cpp does double duty: it
both defines the runtime-agnostic core createNftDataSet and acts as the
WASM entry point by #include-ing markerCreator_bindings.cpp at the bottom
(plus a vestigial #include <emscripten/emscripten.h>).

For the native Python package (#25) the MVP takes the minimal path: guard the
Emscripten-only bits with #ifdef __EMSCRIPTEN__ so the same file compiles both
ways. That works, but leaves the core and the WASM entry point tangled in one
file. This issue tracks the cleaner separation once the native path is proven.

Proposed refactor

Extract the core into its own translation unit with zero binding/Emscripten
coupling:

• emscripten/markerCreatorCore.h — declares createNftDataSet(...) (and any
  shared params/types).
• emscripten/markerCreatorCore.cpp — the implementation (moved out of
  markerCreator.cpp).

Then each entry point just includes the header and provides its binding:

• markerCreator_bindings.cpp (WASM / emscripten) — unchanged behavior.
• python/src/markerCreator_py.cpp (pybind11) — native.

markerCreator.cpp either goes away or becomes a thin WASM-only shim.

Benefits

• Single Responsibility: core logic vs. per-runtime bindings.
• No #ifdef guards or .cpp-includes-.cpp pattern.
• Both tools/makem.js (WASM) and python/CMakeLists.txt (native) compile the
  same core file directly.

Constraints

• WASM build must stay byte-identical (existing Node tests are the oracle);
  validate with a container rebuild + npm test (8/8).
• Update tools/makem.js source list accordingly.
• Pure refactor — no behavior change.

Sequencing

Do this after the #25 spike/MVP proves native compilation works, to avoid
refactoring around an unvalidated build. Relates to #25.