When action level resubmit is unavailable provide a reason in the UI

### Priority

P3 - Medium (Nice to have)

### Feature Area

Monitoring/Run History

### Problem Statement

I previously raised https://github.com/Azure/LogicAppsUX/issues/8968 reporting that the "Submit from this action" button was not appearing in run history in certain workflows.

It was stated there that this button only appears if `canResubmit` is reported as `true` by the API.

It is confusing to the end user why this is sometimes available and sometimes not and what actions we need to take to get this functionality restored.

### Proposed Solution

It seems there are multiple scenarios that can block this functionality. These should be documented.

If `canresubmit : false` was found on an action that was Succeeded, Failed, or TimedOut it would be useful to provide a link to that documentation.

In a perfect world this would also advise the specific blocker case causing the functionality not to be available.

Copilot came up with the following possible reasons for me but I don't know if this is entirely comprehensive/accurate

## Complete list of blockers

The runtime returns `canResubmit: false` for an action if **any** of the following is true:

### Blocker 1 — Host kill‑switch

The host setting `Microsoft.Azure.Workflows.IsResubmitActionsEnabled` is `false` (default: `true`).

**Scope:** All actions in all workflows on the host.

### Blocker 2 — Action not in definition

The action exists in run history but not in the current workflow definition (e.g. the definition was modified after the run).

**Scope:** That specific action.

### Blocker 3 — Repeating action types

The action itself is a `Foreach`, `Until`, or `Agent` (i.e. `IsRepeating() == true`).

**Scope:** That specific action.

### Blocker 4 — Upstream repeating action

Any action earlier in the run's execution order is a `Foreach`, `Until`, or `Agent`. Everything downstream of a loop/agent becomes non‑resubmittable.

**Scope:** All actions after the first repeating action.

### Blocker 5 — Non‑terminal action status

The action is in a non‑terminal state: `Running`, `Waiting`, `Skipped`, `Cancelled`, `Aborted`, etc. Only `Succeeded`, `Failed`, and `TimedOut` pass the `IsActionExecuted()` check.

**Scope:** That specific action.

### Blocker 6 — Workflow graph has no Hamiltonian path (non‑linear graph)

**This is the most common hidden blocker and the hardest to diagnose.** If the **full sequencer graph** (which includes flattened scope internals, not just top‑level actions) contains **any fork** (two or more nodes that depend on the same predecessor), the `HasHamiltonianPath` check fails, causing `ResubmitSequencerType = Distributed`, which makes `isLinear = false`, which forces `canResubmit = false` for **every action in the entire run**.

The runtime flattens all nested actions via `FlattenNestedActions()` and decomposes scope‑typed actions (`Scope`, `If`, `Foreach`, `Until`, `Switch`) into `BeginScope`/`EndScope` pairs. Child actions are wired between these pairs via `PopulateParentDependencies`. This means parallel children **inside** a scope create a fork at the `BeginScope` node — wrapping parallel branches in a scope does **not** help.

Common patterns that trigger this:

| Pattern | Example | Why it breaks |
|---------|---------|---------------|
| Parallel branches | A → B, A → C | B and C both depend on A; in any ordering one won't directly follow the other |
| Scope + error handler at same level | Scope → Delete (SUCCEEDED), Scope → ExceptionHandler (FAILED) | Two actions list the same scope in their RunAfter |
| Fan‑out/fan‑in | A → B, A → C, then D depends on both B and C | Fork at A breaks the path |

**Scope:** All actions in the entire run — even the very first action gets `canResubmit: false`.

**Key insight:** The runtime doesn't care that the fork arms fire on different conditions (SUCCEEDED vs FAILED). The `RunAfter` graph is analysed structurally, not by condition. Two actions depending on the same predecessor = fork = no Hamiltonian path.

### Alternatives Considered

_No response_

### Which Logic App type(s) should this apply to?

Standard

### Additional context

_No response_

Start by locating the action-level resubmit control and the handling of canResubmit in the Monitoring/Run History UI. Trace how unavailable states are represented, then define the documented blocker information the UI can expose. Done when unavailable resubmission actions provide an actionable reason or documentation link for Standard workflows.

Written by the indexing model from the issue text.