Module call events (#59)

Before each "Call" event in our trace which corresponds to a module
initialisation would contain a function name '<module>'. This had two
problems:
* Bad UX when browsing the call trace in the UI
* A runtime_tracing bug currently maps function ids to function names
regardless of file paths. So if two functions from different paths have
the same name they would map to the same function id. This leads to
weird UI behaviour since all module imports are function calls with the
same name '<module>'.

With this change we replace this string with the module name. Note, we
currently have issues deriving the module name, that will be resolved in
future PRs

Author: tzanko-matev

codetracer-python-recorder/CHANGELOG.md

@@ -8,6 +8,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/)
 ### Added
 - Balanced call-stack handling for generators, coroutines, and unwinding frames by subscribing to `PY_YIELD`, `PY_UNWIND`, `PY_RESUME`, and `PY_THROW`, mapping resume/throw events to `TraceWriter::register_call`, yield/unwind to `register_return`, and capturing `PY_THROW` arguments as `exception` using the existing value encoder. Added Python + Rust integration tests that drive `.send()`/`.throw()` on coroutines and generators to guarantee the trace stays balanced and that exception payloads are recorded.
 
+### Changed
+- Module-level call events now use the actual dotted module name (e.g., `<my_pkg.mod>` or `<boto3.session>`) instead of the generic `<module>` label. `RuntimeTracer` derives the name via the shared module-identity helper, caches the result per code object, and falls back to `<module>` only for synthetic or nameless frames. Added Rust + Python tests plus README documentation covering the new semantics.
+
 ## [0.2.0] - 2025-10-17
 ### Added
 - Added configurable trace filters backed by layered TOML files with glob/regex/literal selectors for packages, files, objects, and value domains, strict schema validation via `TraceFilterConfig::from_paths`, and explicit `allow`/`redact`/`drop` value policies summarised with SHA-256 digests.

codetracer-python-recorder/README.md

@@ -82,6 +82,12 @@ selector = "arg:literal:debug_payload"
 action = "drop"
 ```
 
+## Trace naming semantics
+
+- Module-level activations no longer appear as the ambiguous `<module>` label. When the recorder sees `co_qualname == "<module>"`, it derives the actual dotted package name (e.g., `<my_pkg.mod>` or `<boto3.session>`) using project roots, `sys.modules`, and frame metadata.
+- The angle-bracket convention remains for module entries so downstream tooling can distinguish top-level activations at a glance.
+- Traces will still emit `<module>` for synthetic filenames (`<stdin>`, `<string>`), frozen/importlib bootstrap frames, or exotic loaders that omit filenames entirely. This preserves previous behaviour when no reliable name exists.
+
 ## Packaging expectations
 
 Desktop installers add the wheel to `PYTHONPATH` before invoking the user’s

codetracer-python-recorder/src/lib.rs

@@ -8,6 +8,7 @@ pub mod code_object;
 mod errors;
 mod ffi;
 mod logging;
+mod module_identity;
 pub mod monitoring;
 mod policy;
 mod runtime;