Avoid writing history for starts that will be rejected/deduplicated by the workflow-id reuse/conflict policy

When StartWorkflowExecution targets an existing workflow id, the server writes the new run's first history batch (createBrandNew → AppendHistoryNodes) before it resolves the workflow-id reuse/conflict policy. If the policy then rejects or deduplicates the start — REJECT_DUPLICATE, ALLOW_DUPLICATE_FAILED_ONLY on a successfully-completed prior, conflict FAIL, USE_EXISTING, or the terminate paths — that history is already in db and is orphaned. Reclaiming this orphaned history is then job of history scanner only.

This has two costs for self-hosted clusters:

• Write pressure on persistence — every rejected start still performs a history write.
• Storage growth until the scavenger catches up (which runs at most every 12h and skips history younger than a 60-day default)

It's most visible on workloads that use the workflow id for deduplication (e.g. REJECT_DUPLICATE at volume) or that repeatedly start an id while a run is active (conflict FAIL).

1.32.0 added history.businessIDReuseRate, which is checked before the history write — but it's a rate limit, so it only helps the rapid-repeat / hot-id case. It does not apply to policy-based rejections/dedups, which still write history first.

Requested change:

Extend pre-write gating (in the spirit of businessIDReuseRate) to the reuse/conflict-policy paths: when a start targets an existing id, resolve whether it will be rejected/deduplicated before appending history, so doomed starts don't write (and orphan) history.