Add spring-batch-partitioning: manager/worker partitioning, gridSize semantics, rejected-partition recovery, and a real 10M-row scaling sweep

spring-batch-partitioning/docs/output/07-restart-throws-alreadyrunning.txt

@@ -0,0 +1,18 @@
+# Restarting the stuck job: JobExecutionAlreadyRunningException, forever
+
+$ java -jar target/spring-batch-partitioning-1.0.0.jar \
+    --partition.shards-dir=./data/shards-small --partition.grid-size=4 --partition.pool-core-size=4 --partition.pool-max-size=4
+(same shardsDir = same identifying job parameter = same JobInstance = restart target)
+
+Caused by: org.springframework.batch.core.launch.JobExecutionAlreadyRunningException: A job execution for this job is already running: JobExecution: id=1, version=3, startTime=2026-09-14T09:11:21.331474360, endTime=2026-09-14T09:11:21.965090481, lastUpdated=2026-09-14T09:11:21.966521177, status=FAILED, exitStatus=exitCode=FAILED;exitDescription=org.springframework.batch.core.job.JobExecutionException: Partition handler returned an unsuccessful step
+	at org.springframework.batch.core.partition.PartitionStep.doExecute(PartitionStep.java:134)
+	at org.springframework.batch.core.step.AbstractStep.execute(AbstractStep.java:251)
+
+
+The JobExecution row plainly says status=FAILED right there in the exception's own message, and
+SimpleJobOperator still refuses to start a new attempt against it, because its check for "is this
+JobInstance already running" is not "is the JobExecution FAILED" -- it is closer to "does this
+instance have any StepExecution that is not in a terminal status", and the three orphaned
+STARTING/EXECUTING worker steps from docs/06-rejected-partitions-stuck.txt are exactly that. Every
+subsequent `java -jar ... ` against the same shards-dir throws this same exception. The job is
+not failed. It is stuck.