sch_batch, sch_export, sch_analysis and design_review still resolve pins against unit 1

[mixelpixx]

Follow-up from #179, which fixed the multi-unit pin resolution in handle_batch_connect_to_net (the one that silently shorted two nets onto one coordinate). That fix was deliberately scoped; several other call sites still take the first instance carrying a reference, or use unit-blind extract_lib_pins.

A multi-unit part is placed once per unit, all sharing the designator, so "the first instance" is always unit 1 — and a pin owned by unit N transformed by unit 1's placement lands somewhere it doesn't belong.

Still unit-blind on main after #179 and #148:

• crates/konnect-core/src/tools/sch_batch.rs — handle_validate_wire_connections, handle_validate_component_connections
• crates/konnect-core/src/tools/sch_export.rs — two sites
• crates/konnect-core/src/tools/sch_analysis.rs — five sites
• crates/konnect-core/src/tools/design_review.rs — five sites
• crates/konnect-core/src/tools/sch_components.rs — the single-symbol delete/move/rotate/edit paths

Severity differs by site. The validators and analysis tools produce wrong reports rather than wrong files, which is bad but recoverable. The sch_components mutators are the ones to look at first: delete leaves the other units behind as orphans, and move/rotate tear a multi-unit part apart. #179 fixed the batch equivalents of those, so the shapes to copy already exist — find_all_symbol_instance_blocks (tools/mod.rs) and extract_lib_pins_for_unit.

The correct pattern is established in three places now: sch_wiring.rs::resolve_placed_pin (unit-aware, and after #148 also lib_name-aware via find_lib_symbol), and tools/mod.rs::placed_pins.

Acceptance

• Each site either resolves per-unit or has a comment saying why unit 1 is correct for it.
• Regression tests using a two-unit fixture where both units own a pin at the same local coordinate — that is the shape that makes the bug visible.

[mixelpixx]

Adding a call site found while fixing #203: handle_add_component_annotation (sch_components.rs) uses find_symbol_instance_block (singular, first block in file order), so an annotation on a multi-unit part lands only in its first unit block. Same unit-blind shape as the rest of this issue's list.

Noted by @triglav-modular in #203, which is otherwise fixed on main.

[mixelpixx]

Adding a call site found while fixing #203.

handle_add_component_annotation (sch_components.rs) now goes through the property_exists -> update / append_property helpers rather than blind-appending, which fixed the duplicate-property bug. But like the others on this list, it resolves against unit 1 — so on a multi-unit part the annotation lands on the wrong unit's property block.

Same fix as the rest of the list; noting it so it is not missed when this is done properly.