Custom pad-template picker UI with folder-context for the Files app

[Jaggob]

Follow-up to #26 / PR #58.

PR #58 ships two complementary paths for creating a pad from a template:

1. NC-native flow — RegisterTemplateCreatorListener + FileCreatedFromTemplateListener hook into Nextcloud's existing template picker. User puts a template in their configured /Templates folder, NC's + New pad lists it. Limited by NC's single-folder-per-user model and its filename-first-then-template UX (no filename templating possible).
2. API endpoint POST /api/v1/pads/from-template — bypasses NC's TemplateManager. Caller picks any .pad in the user's userspace as the source, passes placeholder-bearing paths, gets back a fully materialised pad in one atomic call. Filename templating works. Folder context is up to the caller. This is the endpoint a custom (non-NC-web) frontend uses.

What remains open: a custom picker UI for the Files app that exposes the from-template endpoint's capabilities through Nextcloud's + menu.

Why the native flow isn't enough for some users

• No filename templating. A template named Protokoll {{date:next monday|d.m.Y}}.pad shows up as a picker entry with {{...}} in its name. NC asks the user to type the new filename before the picker; after our event would rewrite the name, NC's TemplateManager re-fetches by the user-typed path → 403 to the client. PR Pad templates via NC /Templates folder with placeholder substitution #58 documents this and the listener stays read-only on the path.
• No folder-context. NC's template list is single-path-per-user. Teams with different template sets per project area can't have "templates for /Meetings live in /Meetings/.templates, templates for /Decisions in /Decisions/.templates".

Proposal

A new + menu entry "Pad aus Vorlage" that opens our own picker dialog and calls POST /api/v1/pads/from-template directly.

Picker discovery rules (configurable later, hard-coded for v1):

1. Current folder — any .pad file the user is sitting on.
2. .templates / Templates subfolder of the current folder.
3. Walk up the ancestors with the same .templates / Templates check.
4. The user's configured Templates folder as a final fallback.

Templates closer to the current folder rank higher.

The dialog shows:

• The discovered templates (basename, parent folder for context).
• A filename input pre-filled with the resolved filename pattern from the selected template (placeholders applied).
• A submit button that POSTs from-template.

What stays / what changes

• API endpoint stays — already shipped, no change needed.
• NC-native flow stays — useful for users who want the no-frills "+ New pad" → /Templates path.
• New work — the NewFileMenu entry registration (public-pad-menu.js), the picker dialog (vanilla DOM, similar pattern to openExternalPublicPadDialog), the JS API client wrapper for from-template, and the folder-scan logic.

Out of scope

• Editing the placeholder syntax — {{date}} / {{user}} etc. is locked in by PR Pad templates via NC /Templates folder with placeholder substitution #58.
• Sharing templates across other users' shares — group folders are the supported team-share path.
• Visual template thumbnails or rich preview — text-only listing for v1.
• Editing/removing the NC-native flow — both coexist.

Acceptance

• New + menu entry "Pad aus Vorlage" alongside the existing entries
• Picker dialog with folder-scoped template list (current + walk-up + user Templates folder)
• Selected template's filename pattern is rendered into the filename input; user can edit before submit
• Submit POSTs to from-template, opens the new pad in the viewer on success
• No regression in the NC-native template flow
• Tests cover the folder-scan logic and the picker render paths

When

Future / Backlog. The current setup with API + NC-native flow covers the team-share use case via group folders and the custom-frontend use case via the API endpoint. This issue is the upgrade path for the Files-app user who wants folder-aware template discovery and filename templating in NC's own UI.