Surface resolved shell/execution mode in UI, logs, and validation

## Problem

Dagu supports several ways to determine how a step runs: a step-level `shell`, a DAG-level `shell`, the global default shell, shebang-based script execution, and direct execution. That resolution is meaningful because it changes both what interpreter is used and how commands are evaluated.

Today that choice is mostly hidden from users. In the product, authors can define shell behavior in YAML, but the UI, logs, and validation output do not clearly show whether a step will run with `bash`, `zsh`, `shebang`, `direct`, or an inherited/default shell. This makes authoring and debugging harder, especially when behavior differs because a step inherited its shell or switched execution mode at runtime.

The gap is especially confusing for workflows that rely on shell-specific syntax, preconditions, or scripts with shebangs. Users often have to infer shell resolution from docs instead of seeing it directly in the product.

## Expected Behavior

Dagu should explicitly show the execution mode for each step anywhere users need to understand or debug it, including DAG details, DAG run views, step logs, and validation output.

The product should make it clear whether a step is using:
- an explicitly configured step shell
- an inherited DAG shell
- the global default shell
- shebang-based execution
- direct execution

When the exact interpreter cannot be known until runtime, Dagu should say that clearly instead of implying certainty.

## Example

```yaml
name: shell-visibility-example

shell: bash

steps:
- name: uses-dag-shell
command: echo "runs with bash"

- name: uses-step-shell
shell: zsh
command: echo "runs with zsh"

- name: uses-shebang
script: |
#!/usr/bin/env python3
print("runs via shebang")

- name: uses-direct
shell: direct
command: ["/bin/echo", "runs directly"]
```

## Motivation

This closes a real UX gap in a shell-heavy workflow engine.

Making shell choice explicit would reduce authoring mistakes, make debugging faster, and help users understand why the same workflow behaves differently across environments. It also improves trust in validation and run history by showing what Dagu knows, what is inherited, and what is only decided at runtime.

This would unblock workflows that depend on shell-specific behavior without forcing users to over-specify `shell:` everywhere just to make execution understandable.

## Tests

- PR must include integration tests under intg package.

Start by locating the integration tests under the intg package and trace where shell resolution is represented for DAG details, run views, step logs, and validation output. Verify each configured and inherited execution mode is surfaced, while runtime-only interpreter choices are identified as unresolved until execution.

Written by the indexing model from the issue text.