Workflow Templates: custom-node templates can't expose models/tags for the Model/Tasks filters

## Summary

The **Workflow Templates** browser has **Model Filter** and **Tasks** (Use Case) filters that read `template.models` and `template.tags`. These work for first-party (core) templates but are impossible to populate for **custom-node** templates, because custom-node template metadata is discarded when the store builds `TemplateInfo`. As a result, any custom-node template is filtered *out* the moment a user selects any Model or Tasks filter.

## Current behavior

**Backend** — `app/custom_node_manager.py`, `GET /workflow_templates` returns only names:

```py
workflow_templates_dict.setdefault(custom_nodes_name, []).append(workflow_name)
# -> { "MyNodePack": ["my_template", ...] }
```

**Frontend** — `src/platform/workflow/templates/repositories/workflowTemplatesStore.ts` hardcodes every custom template's metadata:

```ts
templates.map((name) => ({
name,
mediaType: 'image',
mediaSubtype: 'jpg',
description: name, // <- description is just the filename
sourceModule: moduleName
})) // <- no `title`, no `tags`, no `models`
```

**Filtering** — `src/composables/useTemplateFiltering.ts` then drops these templates whenever a filter is active, because the field is empty:

```ts
// filteredByModels
if (!template.models || !Array.isArray(template.models)) return false
// filteredByUseCases
if (!template.tags || !Array.isArray(template.tags)) return false
```

So a custom-node template can never participate in the Model/Tasks filters, and its card title/description can only ever be the raw filename.

## Why it matters

Studios and node authors ship curated `example_workflows/` as shared templates. Without metadata, they can't be categorized, titled, described, or filtered alongside the core templates — the filters actively hide them. Core templates get full metadata from the bundled `comfyui_workflow_templates` `index.json`; there's no equivalent path for custom nodes.

## Proposed change

Give custom-node templates the same metadata surface as core templates:

1. **Backend** — let `GET /workflow_templates` include per-template metadata, e.g. by reading an optional `index.json` (or `.json` sidecars) inside the `example_workflows/` folder, with fields mirroring the core template schema (`title`, `description`, `tags`, `models`, `mediaType`, `mediaSubtype`, ...). Templates without a metadata entry keep today's name-only behavior (backward compatible).
2. **Frontend** — in `workflowTemplatesStore.ts`, carry that metadata through into `TemplateInfo` instead of hardcoding `{ mediaType:'image', mediaSubtype:'jpg', description: name }`, so the existing `useTemplateFiltering` logic and card rendering pick it up automatically.

Both are additive/backward-compatible.

## Environment

- ComfyUI `v0.27.0`, `comfyui-frontend-package==1.45.20`

## Workaround (for reference)

Downstream, this can be shimmed client-side by wrapping `api.getCoreWorkflowTemplates` / `api.getWorkflowTemplates` in a registered extension to present a custom pack as a "core"-style category (which already supports `models`/`tags`). It works but couples to those `api` method shapes, so first-class support would be preferable.

Read app/custom_node_manager.py and src/platform/workflow/templates/repositories/workflowTemplatesStore.ts, then compare their custom-template handling with the core template metadata schema. Check src/composables/useTemplateFiltering.ts to understand the required fields. Done means custom-node metadata can populate titles, descriptions, models, and tags while templates without metadata retain current behavior and participate correctly in filters.

Written by the indexing model from the issue text.