Cardano Updates

Server.hs carried a local copy of sealWriteTx that re-entered
cardano-api (toCardanoApiTx + sealedTxFromCardano) to wrap an already
ledger-native balanceTx result. Import the ledger-native sealWriteTx
from Transaction.Ledger instead; the local helper goes away. Two call
sites now pass Write.recentEra explicitly.

Drops the cardano-api bridges cardanoEraFromRecentEra, toCardanoApiTx
and W.sealedTxFromCardano from this module's imports.

The signedTx wrapping in Cardano.Wallet went through
toCardanoApiTx -> inAnyCardanoEra -> sealedTxFromCardano purely to
smuggle the already-ledger tx back through cardano-api. Use the
existing ledger-native sealWriteTx from Transaction.Ledger instead
(now exported). Drops the two cardano-api bridges inAnyCardanoEra and
sealedTxFromCardano from this module.

Also refresh the sealWriteTx haddock (the function has been ledger-
native since the last revamp; the stale comment claimed otherwise).

The function has been an ADP-3077 TODO stub (error "...") for a long
time; the commented-out cardano-api body still referenced
getSealedTxBody and sealedTxFromCardanoBody, which blocks their
removal. Drop the dead block and note that a future implementation
should operate on Read.Tx era via reqSignerHashesTxBodyL.

Mirror the TransactionsNew.hs:getMetadataFromTx port: project metadata
directly from Read.Tx era via Meta.getMetadata . Meta.getEraMetadata
instead of round-tripping through cardano-api. Drops the two callers
of cardanoTxIdeallyNoLaterThan in this file and the Cardano.Api /
ApiEra qualified imports.

Enumerates every remaining caller of the deprecated surface after
#5271: production (Cardano.Wallet.hs, Server.hs), old tx builder
(Shelley/Transaction.hs, partially overlaps with #5243), integration
tests (Shared/Transactions.hs, addRequiredSigners in TransactionsNew)
and unit tests (TransactionSpec, TransactionLedgerSpec).

Organises the work into three phases:
  A. reachable without #5243 (4 sites)
  B. unit-test migration (~20 sites, two files)
  C. delete the bridge functions and the three Cardano.Api*
     imports in SealedTx.hs

feat(release-cli): add Apple notarization via xcrun notarytool in drt…

When the unquoted-identifier parser finishes, require that the next char
is a real word-boundary (not another identifier char and not another
'-'). Otherwise the caller wrote something like `pubKeyHash-305478r71`,
`foo-bar` or `foo-123-456`: the '-NNN' we just consumed as the numeric
unique-suffix is not actually terminal, and the prefix interpretation
would silently mis-parse. Consume the remainder of the extended
identifier so the diagnostic can cite the full bad text, then raise a
new `InvalidIdentifier` custom parser error with a caret on the start
of the identifier and an actionable hint to quote it with backticks.

For the original Scalus 0.16.0 HTLC reproducer this changes the error
from `htlc.uplc:448:39: unexpected '(' expecting ')'` (on a lambda 8+
chars past the real site) to `htlc.uplc:447:41: Invalid identifier
'pubKeyHash-305478r71'` — on the offending name itself.

The three negative goldens added in the previous commit are updated to
the new message; all 3886 tests across plutus-core/untyped-plutus-core/
plutus-ir pass unchanged.

Signed-off-by: William Hankins <[email protected]>

Freeze the current (unhelpful) error output for three forms of invalid
UPLC identifier:
- `foo-bar`                — hyphen followed by non-digits
- `foo-123-456`            — double `-NNN` suffix
- `pubKeyHash-305478r71`   — hyphen + digits + more letters (the shape
  Scalus 0.16.0's `toUplcOptimized` emits, from issue #7742)

All three cases produce misleading diagnostics today — notably the
Scalus case reports the error 8+ characters past the offending name.
Capturing the status quo as goldens so that a follow-up improvement to
name-parser diagnostics shows up as an explicit golden-file diff.