chore: adopt a ruff config and clear the 575 line-too-long / 82 semicolon-statement findings

[domattioli]

Finding

A static-analysis sweep of src/chilmesh, tests, and scripts (ruff --select=F,E) reports 782 findings. The largest classes are stylistic and cannot be fixed safely in a mechanical sweep without producing very large, review-hostile diffs:

Rule	Count	Description
E501	575	line too long (> 88 chars)
E702	82	multiple statements on one line (semicolon)
E402	9	module import not at top of file
E731	5	lambda assigned to a name
E701	3	multiple statements on one line (colon)

E702 is concentrated in the fort.14 reader (CHILmesh.read_from_fort14), where the x = int(...); i += 1 idiom carries the parse cursor. Reformatting those lines touches I/O parsing logic, so it is deliberately out of scope for an automated cleanup pass.

Why this is not a mechanical fix

The repo currently has no ruff/black configuration, so there is no agreed line-length or formatting standard to normalize against. Reflowing 575 lines before that decision is made would create churn that has to be redone. The right sequence is: agree on a config (line length, which E-rules are enabled), add it to pyproject.toml, then apply the formatter in one dedicated commit that reviewers can skip with .git-blame-ignore-revs.

Suggested approach

1. Add a [tool.ruff] section to pyproject.toml with an explicit line-length and select/ignore set. Consider ignoring E501 outright if the project prefers not to wrap, which would resolve 575 findings by policy rather than by edit.
2. Decide separately whether E702 in the fort.14 / gmsh readers should be exempted per-file rather than rewritten.
3. Apply the formatter in a single isolated commit and record it in .git-blame-ignore-revs.

Scope guard

Whatever is chosen must not alter _skeletonize() behavior, public API signatures, fort.14 I/O semantics, or adjacency invariants.

[model: claude-opus, repo: CHILmesh, session: dev-cleanup sweep]