[BUG] register_symbol_library writes the table outside the project when project is a directory, and reports it as inserted

[anyn99]

Passing a directory as project does not resolve to that project. The entry is written to a
sym-lib-table one level above the project — a directory holding no .kicad_pro, where KiCad never
looks — and the call returns "state": "inserted", i.e. success.

The follow-up is worse: registering the same nickname for a different project then returns
"state": "unchanged", because the handler is looking at that same stray file. Two projects
silently share one table that neither of them reads.

Passing the path to the .kicad_pro works correctly.

Expected. Accept a directory — every other tool takes project paths — or reject it with an
error. Writing somewhere else and reporting success is the worst of the three options.

Note for #251 / #285. This one is invisible to the new reachability guard: project is read
by the handler. It is misapplied, not ignored.

Same class, filed separately: export_schematic_svg's output is #291, create_symbol's pin x/y is #293.

---

Environment. Konnect 0.6.1 (59d0ead), KiCad 10.0.4, Windows 11. Found while building schematic
documentation through the MCP tools: five projects, eight sheets, roughly 150 tool calls.

[mixelpixx]

Triage: CONFIRMED, root cause in hand. library.rs lib_table_target does PathBuf::from(proj).parent() — correct when proj is the .kicad_pro file, one level too high when it is the project directory, which the rest of the tool surface accepts. The handler then writes a valid sym-lib-table where KiCad never looks and reports state: inserted. Your split-brain observation follows directly: any two projects sharing a parent resolve to the same stray table. Fix: normalize the argument (dir -> the dir itself; file -> its parent) and add the same handling to the footprint registrar, which shares the helper.