Probe slang-server instance paths headlessly to triage RTL-to-waveform links
When an editor's 'add signal to waveform' fails, check first whether slang-server itself can place the symbol. Spawn slang-server over stdio from a small Python LSP client: initialize with rootUri set to the folder holding .slang/server.json, didOpen the files, wait a few seconds for elaboration, then call workspace/executeCommand slang.getInstances with [{textDocument:{uri}, position}]. A module port returns e.g. ['tb_wrapper.dut.dfp_read'], while symbols in module-less include fragments return []. If the server answers correctly, the bug is in the client's mapping, not the build file. Also run slang -f <build>.f` to confirm the build compiles.
Confirmed with the slang-server v0.3.1 Linux release and a Python stdio client (root = folder with .slang/server.json, didOpen, ~3 s wait). workspace/executeCommand slang.getInstances [{textDocument: {uri: cpu.sv}, position: <on the clk port>}] returned ['tb_wrapper.tb.dut.clk'] for a cpu instantiated under top_tb under tb_wrapper. The same call on a signal declared in a module-less `include fragment (inc.svh, included into tb_wrapper) returned [], even though getScope ["tb_wrapper"] does list that signal. So the empty result there is the server's behaviour for include fragments, not a broken build.