fix: use deterministic keys in element! macro for reproducible builds

[domenkozar]

Summary

• Replace Uuid::new_v4() with a deterministic atomic counter for element declaration keys in the element! macro
• Remove the uuid dependency from iocraft-macros
• Add test verifying key determinism across invocations

Problem

The element! macro uses Uuid::new_v4() to generate unique keys for each element declaration. Since Uuid::new_v4() reads from /dev/urandom, it produces different output on every compilation. This makes any crate using element! non-reproducible: two compilations of the same source with the same flags produce different .rmeta and .o files.

This breaks build systems that rely on reproducible builds, such as Nix with crate2nix/buildRustCrate. In that setup, crates are compiled independently and can be cached. When a cached crate has different metadata (SVH) than what a locally-built dependent expects, rustc produces E0463 "can't find crate" link errors.

Fix

Proc macro expansion order is deterministic within a compilation, so a simple atomic counter produces stable, unique keys. The counter resets to 0 at the start of each compilation (since proc macro state is not persisted), ensuring identical output for identical input.

Test plan

• All existing tests pass
• New deterministic_keys test verifies same call site produces same key and different call sites produce different keys

🤖 Generated with Claude Code

[ccbrown]

Thanks for the PR!

I think there are situations where this could cause conflicts. For example, a library which provides a component like so might encounter conflicts since the static variable is scoped only to each compilation unit (i.e. there can be more than one component with the 0 key):

element! {
    Foo {}

    #(children)
}

Maybe there's a way to guarantee uniqueness across compilation units by using proc_macro::Span::call_site() or something similar?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.71%. Comparing base (d614ffa) to head (c2d4a82).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #187   +/-   ##
=======================================
  Coverage   87.71%   87.71%           
=======================================
  Files          35       35           
  Lines        5525     5526    +1     
  Branches     5525     5526    +1     
=======================================
+ Hits         4846     4847    +1     
  Misses        570      570           
  Partials      109      109           

Files with missing lines	Coverage Δ
packages/iocraft-macros/src/lib.rs	94.24% <100.00%> (+0.01%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[domenkozar]

Thanks for the review! Good catch on the cross-crate collision issue.

I've updated the implementation to include module_path!() in the generated keys, so the key is now (module_path!(), counter) (or (module_path!(), counter, user_key) when a user provides a key). Since module_path!() always starts with the crate name and Cargo enforces unique crate names in a dependency graph, this guarantees uniqueness across compilation units. The counter continues to handle within-crate uniqueness.

[ccbrown]

Lgtm!