Feature Request: Support HTML preview for directory artifacts with previewPath

### **Problem Statement**
When using `archive: none: {}` to save directory artifacts containing HTML reports, the Argo UI cannot preview HTML files within the directory, which creates inconvenience for viewing test reports and similar use cases.

### **Use Case**
I encountered this issue when generating Playwright test reports:

**Playwright Report Structure:**
```
playwright-report/
├── index.html # Main report file
├── data/ # Test data zip files
│ ├── 7c5cc25bbfc8a999055e8198ded3e650523af867.zip
│ └── 9a302936ee338de3179e9cb5d654aae316cd8005.zip
└── trace/ # Failed test case trace viewer
├── index.html # Trace viewer entry point
├── assets/ # JS modules
├── *.css # Style files
├── *.js # Script files
└── *.html # Other pages
```

**Current Configuration:**
```yaml
outputs:
artifacts:
- name: playwright-report
path: /playwright-report
archive:
none: {}
```

### **Current Behavior**
- Directory artifacts are displayed as folders in the UI with no preview capability for `index.html`
- If HTML files are output separately, the entire directory structure is lost, preventing access to:
- Trace files for failed test cases (stored in `data/` zip files)
- The trace viewer (`trace/index.html`) and its dependencies
- All interactive report functionality

### **Proposed Solution**
Add support for HTML preview in directory artifacts while preserving the complete directory structure.

**1. Extend Artifact Specification** with a `previewPath` field:
```yaml
outputs:
artifacts:
- name: playwright-report
path: /playwright-report
archive:
none: {}
previewPath: index.html # Specify preview entry file
```

**2. UI Logic Updates:**
- Detect the `artifact.previewPath` field in `artifact-panel.tsx`
- Display preview button when `previewPath` exists
- Access preview via `{artifact-base-url}/{previewPath}`

**3. Backend Support:**
- Ensure artifact service can access relative path files within directories
- Support relative path references within directory artifacts

### **Implementation Details**
**Current code** in `ui/src/workflows/components/workflow-details/artifact-panel.tsx:40-41`:
```typescript
const tgz = \!input && \!artifact.archive?.none;
const supported = \!tgz && (isDir || ['gif', 'jpg', 'jpeg', 'json', 'html', 'png', 'txt'].includes(ext));
```

**Suggested modification:**
```typescript
const tgz = \!input && \!artifact.archive?.none;
const hasPreviewPath = artifact.previewPath && \!tgz;
const supported = \!tgz && (hasPreviewPath || isDir || ['gif', 'jpg', 'jpeg', 'json', 'html', 'png', 'txt'].includes(ext));
```

### **Benefits**
- **Backward Compatible:** Does not affect existing artifacts
- **Flexible:** Users can specify any preview entry file
- **Preserves Functionality:** Maintains directory structure and file references
- **General Solution:** Useful for various HTML report types (test reports, documentation, etc.)

### **Alternative Considered**
Auto-detecting `index.html` in directories was considered, but the explicit `previewPath` approach provides more flexibility and clearer intent.

Start in ui/src/workflows/components/workflow-details/artifact-panel.tsx at the current preview support logic, then trace the artifact specification and backend artifact service described in the issue. Done means a directory artifact can declare previewPath, the UI offers its preview, and relative files and dependencies remain accessible.

Written by the indexing model from the issue text.