X/driver tracing: a testbench force on a signal that also has a local driver must make the step approximate, not exact

This is a pitfall in an RTL driver/X-tracing engine that combines static analysis (slang AST) with dumped waveform values. To find who wrote a signal, the engine considered only the instance's own drivers, and used outside writers (testbench force/$deposit, hierarchical assignments) only when the instance had none. So when a testbench forced a signal that also had a normal driver, the step was attributed to the local driver and marked 'exact'. A forced value that disagreed with the local logic would then show up as unexplained. Fix rule: if the local drivers cannot explain the dumped value at that time (their predicted value differs from the dump) and outside writers exist, include the outside writers as candidates and mark the step approximate with a 'force' reason; never exact. A related set of rules that came out of the same review: treat name arguments to unknown system tasks (vendor $deposit-like tasks) and module variables written inside called task/function bodies as possible writes, again approximate. Keep a mutant test for each guard, because 'adds a candidate, never removes one' rules are easy to break silently.