[New Feature]: Find a better way to handle `Nightly` packages.

Description of the new feature/enhancement

Packages which are actually updated every ~24 hours currently aren't really a good fit for this package manager. Our validation and approval timing means they will at best be available only ~75% of the time, and sometimes will miss for several days.

General timing:

• Developer releases new nightly. (Immediate hash mismatch.) (0 hours)
  • Ideal: the developer has added a PR in our repo to their CI/CD process.
  • Slower: a community member has detected this in some way and created a PR. ("Slower" because there might be a delay between the developer's release and the community member's schedule, introducing additional delay into the process. Add ~1 hour.)
• PR in repo, validation pipelines start. (Hour 0 or 1)
  • Ideal: Pipelines complete (Hour 1 or 2)
  • Slower: Pipelines have either a pipeline error (IEDS) or a package error (other labels). Needs remediation, add ~3 hours. (Hour 4 or 5)
• PR "greenlit" for approval.
  • Ideal: Immediately before an approval run (~7 am or ~5 pm - Hour 1 or 2 / 4 or 5)
  • Slower: Several hours before an approval run. (Add ~3 hours - Hour 4 or 5 / 7 or 8)
• Publish pipeline runs and new version of package becomes available.

The most ideal scenario consumes around 16% to 20% of the Nightly package's lifespan. A slightly impacted but still mostly ideal scenario consumes 33%. Additional delays in this process can easily consume the remaining timespan between releases.

Proposed technical implementation details (optional)

Neither of these ideas is really ideal in the current situation, so please be gentle.

One idea:
The number of manual steps complicates expediting the validation and approval process. There might be some kind of expedited system, where certain developers can become vetted in some way (Authorized Publishers?) and have their nightly packages fast-tracked into the Publish pipeline, while the validation and approval steps are pending. And with the caveat that any failure of those pipelines would cause that nightly version to become reverted. This might present too many legal fronts (not a laywer).

Other idea:
"Known Nightlies" could have a flag, or be on a list, or otherwise enumerated such that they could have reduced restrictions on hash mismatches. The package manager could allow hash mismatch overrides - in conjuntion with the above enumeration. (This might be hidden deep behind large security warnings, where only advanced users (who would opt for a nightly version of a package) would know to enable.) This would allow users with a large risk appetite to continue receiving nightly updates.

No files, tests, or concrete entry points are named. Start by mapping the validation, approval, and Publish pipelines described in the issue, then clarify whether the intended outcome is an expedited path, Known Nightlies handling, or both; the issue does not yet define a settled implementation or completion criteria.