docs(workflow): fix concurrency-policy status wording and align SDK reference

Two Copilot review findings on #166:

- The Concurrency Control intro implied both policies hold excess work
  in PENDING, but the job function execution policy suspends the running
  workflow to PENDING_RESUME (not PENDING). Rewrite the intro to
  distinguish the two states.
- The SDK reference still said "longest matching prefix wins" for
  overlapping wildcard policies, contradicting the AND-of-caps behavior
  documented in the guide (matches the current platform implementation).
  Update the SDK page to describe the stacking behavior. The auto-sync
  from tailor-platform/sdk will need a matching upstream fix; this edit
  keeps the two pages consistent in the meantime.

Author: k1LoW

docs/guides/workflow/index.md

@@ -97,7 +97,7 @@ Job functions within a single workflow execute **sequentially**, not in parallel
 
 ## Concurrency Control
 
-In addition to the [platform-wide caps](/reference/platform/platform-limits#workflow-concurrency-limits) (50 per workspace, 20 per workflow), workflows can declare two independent concurrency policies. Both hold excess work in `PENDING` state rather than rejecting it, but they operate at different points in the execution lifecycle.
+In addition to the [platform-wide caps](/reference/platform/platform-limits#workflow-concurrency-limits) (50 per workspace, 20 per workflow), workflows can declare two independent concurrency policies. Neither rejects excess work, but they defer it in different ways: the workflow-level policy keeps new executions in `PENDING` at the scheduler, and the job function execution policy suspends the running workflow to `PENDING_RESUME` at dispatch time. Both resume automatically as slots free up.
 
 ### Workflow-level Concurrency Policy
 

docs/sdk/services/workflow.md

@@ -397,7 +397,7 @@ export default defineConfig({
 
 `key` accepts `[a-z0-9_:.-]` and must start with `[a-z0-9]`. An exact key must also end with `[a-z0-9]`; a wildcard prefix (`matchType: "prefix"`) may end with any of those characters, since the platform appends a trailing `*` after it. The platform-registered key — including that trailing `*` when wildcarded — is 2 to 64 characters long, so a wildcard prefix must be at most 63 characters. `foo:bar` is a valid exact key; `tenant-api` with `matchType: "prefix"` registers `tenant-api*` as a wildcard prefix.
 
-An exact-key policy applies to dispatches whose runtime key equals the policy key. A wildcard policy applies to every dispatch whose runtime key begins with the prefix; each concrete resolved key gets its own independent pool of the declared size (a `cap = 3` wildcard yields three concurrent dispatches per resolved key, not three across every match). The longest matching prefix wins when a dispatch could match more than one wildcard.
+An exact-key policy applies to dispatches whose runtime key equals the policy key. A wildcard policy applies to every dispatch whose runtime key begins with the prefix; each concrete resolved key gets its own independent pool of the declared size (a `cap = 3` wildcard yields three concurrent dispatches per resolved key, not three across every match). Overlapping policies **stack**: when a dispatch key is covered by more than one policy (any mix of exact and wildcard prefixes), every covering policy applies, the dispatch acquires one slot in each matching pool, and any single saturated cap blocks it. See [Concurrency Control](/guides/workflow/#job-function-execution-policies) in the Workflow guide for the AND-of-caps behavior.
 
 ### Referencing a Policy from a Workflow