Validate pin identifiers in Component pins map

[akhilles]

We shouldn't allow . in pin names as parsing it becomes ambiguous.

---

Note

Low Risk
Small, localized validation change that may surface new errors for designs previously using dotted/invalid pin names, but does not affect security or data integrity.

Overview
Component(pins=...) now validates each pin name using validate_identifier_name, rejecting non-identifier keys (ASCII-only, non-empty, no whitespace, and disallowing ./@) at component construction time.

Tests add a lightweight eval_single_file helper and a new regression test that asserts dotted pin names fail evaluation, and docs/CHANGELOG.md are updated to document the new pin-name constraint.

^{Written by Cursor Bugbot for commit 2726298. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Missing pin name validation in pin_defs path

Medium Severity

The new validate_identifier_name call validates pin names from the pins dict but not from the pin_defs dict. Since pin_defs keys become signal names in the symbol, a user can define a pin with a dot (e.g. pin_defs = {"NC.1": "1"}) and the invalid name enters the system unchecked. Worse, if that pin is later referenced in pins, the validation rejects it — creating pins that are definable but unconnectable.