Create ISetupCheck support implementation #6590

Is your feature request related to a problem? Please describe.

Create a GitHub issue proposing the implementation of Nextcloud's ISetupCheck interface in LibreSign. This requires refactoring ConfigureCheckService.php into 6 specialized check classes (Java, JSignPdf, PDFtk, Poppler, Imagick, CertificateEngine) that implement ISetupCheck. The issue should categorize checks by criticality and include priority levels, since some (Java, PDFtk, JSignPdf, CertificateEngine) are mandatory for LibreSign functionality, while others (Poppler, Imagick) are optional.

Describe the solution you'd like

1. Define issue scope and motivation – Explain what ISetupCheck provides (admin panel visibility, CLI integration via occ setupchecks) and why implementing it improves UX for Nextcloud administrators managing LibreSign.

2. Create priority table – Map the 6 checks (Java, JSignPdf, PDFtk, Poppler, Imagick, CertificateEngine) with columns: check name, current location in ConfigureCheckService, priority (must-have/nice-to-have), and dependencies.

3. Include implementation details – Outline the refactoring approach: create lib/SetupCheck/ folder, extract logic from ConfigureCheckService methods, convert ConfigureCheckHelper results to SetupResult objects, register checks in Application::register().

4. Link reference documentation – Include links to Nextcloud ISetupCheck documentation and examples from the codebase (PhpModules, CodeIntegrity, SecurityHeaders, MaintenanceWindowStart, WebdavEndpoint).

5. Add conditional logic notes – Document that CFSSL-dependent checks (CertificateEngine) need conditional status handling and explain how optional checks (Poppler, Imagick) should return info() vs error() severity.

6. Specify testing and Git requirements – Note that LibreSign requires Conventional Commits, sign-off (git commit -s), and focused test runs with --filter flag (per copilot-instructions.md).

Describe alternatives you've considered

1. Backward compatibility – Should ConfigureCheckService.php remain for existing code/tools, or be deprecated once ISetupCheck classes are in place? Recommend keeping for now.

2. Category assignments – Most checks are "system" severity; only CertificateEngine should be "security". Confirm this aligns with LibreSign's security model.

3. Visibility control – Should checks be conditional (only visible when LibreSign is configured)? Current implementation in setup/install flows may differ from always-visible admin panel.

Additional context

• If you have questions, feel free to ask in this issue.
• Give a ⭐️ star to this repository

This task is suitable for first-time contributors!