Improve validation for sibling pages security

[lenverstijnen]

Ticket:

Description of changes

In the past, if you had a parent page with that was not published, and you've added children to it, you weren't able to publish it anymore, due to the validation. This is now fixed. You are now able to publish parent pages that have not been published before. After the page has been published, you can't change the slug anymore if it has children. This is how it should work.

How to validate the changes

Tobias and I tested this in the British Library project.

• Make a new page and don't publish it.
• Make children pages.
• Try to publish the parent page, this should work.
• After that, publish the children.
• After that you shouldn't be able to change the slug of the parent page anymore.

✅ Definition of Done

This checklist helps with risk management during software development. It is not a mandatory list to fully check off, but a basis for thinking about quality, safety, and best practices. Feel free to adapt it for your own project — as long as the risks are consciously managed.

📄 Documentation & Knowledge Sharing

• Changes are documented in the code and/or README.md
• Relevant Notion pages are updated

🧪 Testing & Quality

• Changes are covered by unit/integration/end-to-end tests
• GitHub Actions (CI/CD) pass successfully
• Reviewer has tested and verified the changes locally

📊 Monitoring & Performance

• Relevant metrics (e.g. in Datadog) are added or updated
• Performance and scalability have been considered and tested if needed

🔐 Security & Privacy

• The changes comply with our Secure software development policy
• No personal data or privacy-sensitive information is affected
• Input validation, authentication, and authorization are properly handled

🧩 Traceability & Readiness

• A Jira ticket is linked, and the ticket number is in the PR title (e.g. [R2025-1234] Meaningful title)
• No unresolved TODOs remain in the code (unless followed up with a Jira ticket)

🤝 Review & Collaboration

• Code is reviewed by at least one team member
• Merge responsibility and timing are agreed upon
• Team members are informed (e.g. via Slack or daily stand-up)