Two fixes to the pending upgrade fragments, found by reading them
together as the release guide a user will get.

**The order of steps.** Five fragments tell the user to run `prisma
contract emit`. The `data-type-in-contract` fragment's script must run
before any of them, and `prisma db sign` must see the contract the
database was created from before a re-emit changes it. Only its
enum-list paragraph said so. Its first paragraph now says it for every
case:

> Do this before any other step of this release that re-emits a
contract: the script changes only files in the old format, and `prisma
db sign` must see the contract the database was created from before a
re-emit changes it again.

**What the application does with an unsigned database.**
`bytea-defaults-verify` said the application logs
`CONTRACT.MARKER_MISMATCH`. `data-type-in-contract` and
`brownfield-date-types-are-text` say it logs nothing, because the
`postgres()` client has no logger for the marker check, which manual QA
observed. The bytea fragment now says the same as the other two.

`pnpm lint:docs` and `pnpm check:upgrade-coverage` pass.

Agent: minerva-41


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
* Clarified that `prisma db verify` reports a marker mismatch after
contract re-emission until the database is signed or the migration is
applied, while the application continues serving queries without logging
a mismatch.
* Clarified that the data-type upgrade step must run before other steps
that re-emit a contract, and that signing uses the pre-re-emission
contract.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>