Split `make up` into two phases: a plain `pulumi up` first, then
`pulumi up --refresh`. Dynamic providers serialize their implementation
into state at create/update time. During refresh, the serialized `read()`
runs — so any provider-code change (like the Discord 429 retry logic)
doesn't take effect until a successful update writes the new `__provider`
to state. Running refresh first used the stale serialized code from the
last successful deploy, which had no rate-limit handling, failing on
parallel Discord member lookups.
Also bump discordFetch maxRetries from 5 to 10 for headroom against ~68
parallel refresh reads.
ffa85f0109