Force redeploy should preserve content-addressed digest and trigger via Pulumi, not a random blob name

Background

PR #2255 fixed a bug where `--force` reused one upload URL after its first use, so the CD build was silently skipped and a stale image was shipped. The fix generates a fresh UUID-named blob for every forced upload, guaranteeing the build context URL differs each time.

Follow-up

@lionello raised a better long-term design: keep uploading under the content sha256 digest (so identical uploads still dedupe in blob storage, and unforced deploys keep working exactly as before), and instead push the "force" intent down to where the deploy decision actually lives — the Pulumi/CD side — using one of Pulumi's own trigger mechanisms (e.g. a `triggers`-style resource dependency, or a random/timestamp input) to force the build/deploy step to re-run even though the S3 URL is unchanged.

This needs:

• `CreateUploadURL`/`UploadURLRequest` (or equivalent) to carry the force intent through to the CD runner, instead of only the CLI knowing about it.
• A trigger mechanism in the `pulumi-defang` provider's build/deploy resource so it forces re-execution independent of the S3 build-context URL.

Note: this doesn't need a fabric RPC change routed through Playground — Playground is obsolete, so this is scoped to BYOC providers (`pulumi-defang`) and the CLI's request to `CreateUploadURL`.

Why not do this in #2255

#2255 is a hotfix for images actively being shipped stale in production; the digest-preserving/Pulumi-trigger redesign spans multiple repos and is a bigger lift, so it's tracked here separately rather than blocking the hotfix.

Trace CreateUploadURL/UploadURLRequest in the CLI and the build/deploy resource in the pulumi-defang provider. Determine how to carry the force intent while preserving the content-addressed S3 upload digest, then examine Pulumi trigger mechanisms. Done means repeated forced deployments rerun the build/deploy step without changing the digest-based upload URL.