Wait for running jobs when XWiki stops and mark interrupted jobs in their stored status

Finding from the Kubernetes test cluster (ciaens/xwiki-k8s, docs/k8s-results.md, 2026-10-11), with the first version of this change deployed: the worker pod was deleted (SIGTERM, 120 s grace period) 3 s after a 150-page space move started. DefaultJobExecutor#dispose() waited for the job as intended and the status was stored as FINISHED without error, but only about 50 of the 150 pages got their automatic redirect, back-link update, parent-field update and index tasks: every listener on DocumentRenamedEvent failed silently once the shutdown had started, while the renames themselves kept succeeding at the database level.

Cause: the executor ran its wait at the default dispose priority (1000). The component manager had already disposed, in the same pass, the Solr indexer (priority 500), the S3 client, the Infinispan caches (ISPN000323: Cache 'configuration.document.space' is in 'TERMINATED' state on every index task) and the job log capture, so the job finished inside a half-disposed system and the job log stopped before the SIGTERM. A graceful stop that leaves a silently incomplete refactoring is worse than the previous behaviour.

Fix added to the branch: DefaultJobExecutor is now annotated @DisposePriority(100) so that the wait for running jobs happens before any other component is disposed. Reference run without pod deletion: 150 pages moved and 150 redirects in 44 s.

Noticed at the same time, outside this issue: SolrEventStore logs Failed to commit ... Connection pool shut down at shutdown because the Solr client is closed before the asynchronous event store flushes its queue (dispose order between xwiki-platform-search-solr-api and xwiki-platform-eventstream-store-solr); tracked separately.