[SPARK-60146][PYTHON] Use len for MLlib vector dimensions

[bearomorphism]

What changes were proposed in this pull request?

Replace five .size accesses with len() in pyspark.mllib.classification, covering coefficient dimensions, multiclass prediction, and streaming initial weights. This removes four redundant type: ignore[attr-defined] comments.

The Vector base class and concrete implementations remain unchanged. Suppressions for undeclared methods such as dot() are outside this PR's scope.

Why are the changes needed?

Vector already declares __len__(), and existing dot-product and squared-distance dimension checks rely on it. Both built-in vector implementations return their logical dimension from len(), including trailing zeros in sparse vectors.

Using this existing interface avoids relying on an undeclared .size attribute or adding .size as a new requirement for all Vector subclasses.

Does this PR introduce any user-facing change?

No behavior change for the built-in DenseVector and SparseVector implementations. Custom subclasses used by these classification paths must implement the existing Vector.__len__() interface; providing only .size is no longer sufficient for these dimension accesses.

How was this patch tested?

Passed:

mypy --config-file python/mypy.ini --follow-imports=silent python/pyspark/mllib
ruff check python/pyspark/mllib/classification.py
ruff format --check python/pyspark/mllib/classification.py
git diff --check

Temporary Python checks passed 38 scenarios both before and after the revision, covering dense/sparse weights and features, multiclass prediction with and without bias, trailing zeros, and streaming initialization with empty, all-zero, and nonzero weights.

No permanent tests were added for this cleanup. No JVM-backed test suites were run.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Pi 1.1.0

[bearomorphism]

After taking a second look I think we need a deeper discussion on the fix.