ci: run python lint on tests/ and docs/, as its own job - #896

Merging the latest rjurney/pypi-tutorials in to test the neo4j.py
fixes against a clean base surfaced an invalid pyproject.toml already
sitting on that branch (from "Merge branch 'main' into
rjurney/pypi-tutorials", 37df7b9): the [tool.black] section had two
leftover merge-conflict remnants, a stray `'''` and `=======`, making
the file invalid TOML. That breaks poetry, black and isort outright
for anyone on the branch.

Removed both stray lines. That still left `force-exclude` combining
main's proto exclusion with this branch's tutorials-data exclusion as
a Python list - `["/graphframes/connect/proto/", "/graphframes/tutorials/data/"]`
- which black's own `--verbose` output confirmed matches every path
("ignored: matches the --force-exclude regular expression" on files
that match neither string): `force-exclude` needs a single regex
string, not a list, the exact same mistake `include` had before graphframes#896
fixed it. Combined both into one regex string with alternation
instead.

Verified: `python -c "import tomllib; tomllib.load(...)"` now parses
cleanly; `black --check` now finds and correctly formats 40 real
files while still excluding graphframes_pb2.pyi and
tutorials/data/*; isort and flake8 both clean; poetry check/poetry
check --lock clean; full local test suite (109 tests) passes.

Co-authored-by: Russell Jurney <rjurney@users.noreply.github.com>

…oordinates (#10)

* fix(python): repair corrupted pyproject.toml on rjurney/pypi-tutorials

`poetry install`/`poetry check` currently fail outright on this branch:

    Invalid TOML file /workspace/python/pyproject.toml: Unexpected end
    of file at line 137 col 0

The [tool.black] section has two leftover merge-conflict remnants - a
stray `'''` and `=======` - left behind by "Merge branch 'main' into
rjurney/pypi-tutorials" (37df7b9), making the file invalid TOML.
Removed both stray lines.

That still left `force-exclude` combining main's proto exclusion with
this branch's tutorials-data exclusion as a Python list -
`["/graphframes/connect/proto/", "/graphframes/tutorials/data/"]` -
which is the same mistake `include` had before graphframes#896 fixed it: black's
own `--verbose` output confirms a list there matches *every* file
("ignored: matches the --force-exclude regular expression" on files
that match neither string), not just the two intended paths.
`force-exclude` needs a single regex string. Combined both exclusions
into one string with alternation instead.

Verified on a clean checkout of origin/rjurney/pypi-tutorials:
- `poetry check` and `poetry install --with=dev` both now succeed
  (they currently fail with exit code 1 on this branch as-is).
- `python -c "import tomllib; tomllib.load(...)"` parses the file.
- `black --check` now finds and correctly formats all 40 real Python
  files under graphframes/tests/docs/dev, while still excluding the
  generated graphframes_pb2.pyi and everything under
  graphframes/tutorials/data/.
- `isort --check` and `flake8` both clean.
- `poetry check --lock` clean (no lock-file drift from this fix).
- Full local test suite: 109/109 passing.

Co-authored-by: Russell Jurney <rjurney@users.noreply.github.com>

* fix(neo4j): use the Neo4j connector's actual current Maven coordinates

Ran the full tutorial for real to check it: downloaded the real
stats.meta.stackexchange.com dump, built Nodes/Edges.parquet, stood up
a real Neo4j server (no Docker available, so the plain tarball
distribution instead - same Bolt/HTTP endpoints `graphframes neo4j
setup` would give you), ran `graphframes neo4j load` against it, then
spark-submit'd neo4j.py for real. That surfaced two real bugs in the
documented Maven coordinates, both invisible to a plain dependency
resolution check because Ivy silently follows Maven relocation POMs:

1. `org.neo4j:neo4j-connector-apache-spark_2.13:6.0.0_for_spark_4` is
   a relocation stub - Neo4j moved the connector to
   `org.neo4j.connectors:spark` at 6.0.0. It still resolves and runs,
   but points at a coordinate Neo4j's own docs no longer document, so
   switched every reference to the live one:
   `org.neo4j.connectors:spark:6.0.0-s_2.13`.
2. `6.0.0_for_spark_3` relocates to the exact same Spark-4-only jar as
   `6.0.0_for_spark_4` - the message on the relocation POM says so
   outright ("requires Spark 4 with Scala 2.13") - so the tutorial's
   Spark 3.5 guidance was actually pointing Spark 3.5 users at a jar
   that cannot load under Spark 3.5. Confirmed the failure directly
   (`NoClassDefFoundError: scala/$less$colon$less`, a Scala 2.13-vs-2.12
   class loaded under a Scala 2.12 Spark 3.5 runtime) and confirmed the
   fix: `graphframes-spark3_2.12:0.12.1` (PySpark 3.5 ships Scala 2.12,
   not the 2.13 the tutorial suggested) with
   `neo4j-connector-apache-spark_2.12:5.4.3_for_spark_3`, the last
   connector line that actually targets Spark 3.5.

Also aligned `neo4j_cli.py`'s NEO4J_PACKAGE constant (used for `load`'s
own SparkSession, built outside spark-submit) to the same live
coordinate, and noted there that `load` specifically needs a Spark 4.x
PySpark install regardless of which Spark version `neo4j.py` targets.

Verified end to end, twice, against the real Neo4j instance with the
real 129,751-node/97,104-edge graph, using the exact corrected
commands:

- Spark 4.1.3 (poetry's pinned dev dependency), packages
  `graphframes-spark4_2.13:0.12.1,org.neo4j.connectors:spark:6.0.0-s_2.13`:
  `graphframes neo4j load` then `spark-submit .../neo4j.py` both ran
  clean, producing the exact counts the tutorial documents (40,115
  components, the 56,442-node/6-type giant-component breakdown, the
  same top-10 decorated users by badge count), and the write-back
  actually landed - every one of the 129,751 nodes came back out of
  Neo4j with a `component` property afterward.
- Spark 3.5.8 in an isolated venv (PySpark's actual bundled Scala,
  2.12), packages
  `graphframes-spark3_2.12:0.12.1,org.neo4j:neo4j-connector-apache-spark_2.12:5.4.3_for_spark_3`:
  same script, same real Neo4j data, identical results.

Confirmed the currently-documented (pre-fix) coordinates actually fail
under Spark 3.5 by running them as-is first and reproducing the
NoClassDefFoundError, then confirmed the fix resolves it - not just
that the new coordinate exists on Maven Central.

black/isort/flake8 clean; full local suite (109 tests) still passes.

Co-authored-by: Russell Jurney <rjurney@users.noreply.github.com>

---------

Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: Russell Jurney <rjurney@users.noreply.github.com>