fix: deterministic SHACL output + workerd-friendly createNamespace imports

[renanpontez]

Summary

Two small follow-ups to #172 (SHACL → schema CLI converters):

1. Deterministic property order.
   a. n3 Store quad iteration order isn't guaranteed stable across parses, so re-running shacl-to-schema against the same input could produce noisy diffs in generated files.
   b. Properties are now sorted alphabetically before emit. Adds a regression test covering this.

2. Workerd-friendly createNamespace import path.
   a. The generated code (and a couple of internal scripts) imported createNamespace from the root ldkit entrypoint. That entrypoint transitively pulls in modules that don't load in Cloudflare Workers / workerd.
   b. Switched all 4 call sites (scripts/extract_namespace.ts, scripts/schema_to_script.ts, scripts/schema_to_package.ts, plus the generator) to import from ldkit/namespaces, which is the narrow, side-effect-free entrypoint.
   c. Tests updated to match.

Both issues were surfaced while consuming the converter in a workerd-deployed project after #172 landed.

Test plan

• deno test tests/scripts/shacl_to_schema.test.ts tests/scripts/schema_to_script.test.ts — 47 passed, 0 failed
• New determinism test exercises the alphabetical-order invariant against intentionally out-of-order SHACL input

[renanpontez]

Heads up on the failing fmt-lint-test check. It looks like the same Deno/cross-fetch resolution issue you flagged on 172. Lmk!

[karelklima]

@renanpontez Thanks for the fix, looks good to me. I released a new version of LDkit (2.7.1) that includes the fix.

You are correct regarding the CI issue - it it indeed Deno related and should be resolved with the next Deno release.