Drop parent constraints from notes_archived table

What does this MR do and why?

This table is used as a backup for notes we cannot find a relevant sharding key on. So we know inserts won't actually have the columns present that the constraint is checking.

Migration was introduced in Backfill the namespace id for notes with null p... (!191155 - merged) and I have raised the issue in !191155 (comment 2789387488)

So, in .com we have multiple failed jobs with

PG::CheckViolation: ERROR:  new row for relation "notes_archived" violates check constraint "check_82f260979e"

Dropping the constraints should fix the error as we don't need that constraint in the archive

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #444222