Support remote boilerplate URLs in Template blocks

[odgrim]

Right now, the Template component only supports local paths relative to the runbook directory. It'd be useful to also support remote boilerplate template URLs (e.g. git URLs like github.com/org/repo//path/to/template), since boilerplate already has built-in support for this via TemplateURL.

What needs to change

The current flow in HandleBoilerplateRender does a filepath.Join with the runbook directory and then an os.Stat check, which obviously won't work for remote URLs.

We'd need to:

1. Detect whether templatePath is a local path or a remote URL
2. For remote URLs, skip the local path resolution and existence check
3. Pass the URL through to boilerplate's TemplateURL option and let it handle the cloning/fetching
4. For local paths, keep the existing behavior

Things to consider

• Boilerplate clones remote templates to a temp directory. We should make sure cleanup happens properly on both success and failure.
• Network errors will need clear error messages so users aren't confused when a URL is unreachable.

[josh-padnick]

@odgrim I won't be able to run with this, but here's a plan file I was playing with that might be a helpful start!

# Support Remote Boilerplate URLs in Template Blocks

## Context

Issue: gruntwork-io/runbooks#101

The `<Template path="...">` component currently only supports local paths relative to the runbook directory. The underlying boilerplate library and the codebase's git infrastructure already support remote sources — the TfModule component uses `resolveRemoteSource()` to clone remote repos. This change wires the same pattern into the boilerplate config and render endpoints so runbook authors can write:

```mdx
<Template id="vpc" path="github.com/acme/templates//vpc?ref=v1.0" />
```

## Approach

Reuse the existing `resolveRemoteSource()` function from `tf_parse_handler.go` in both boilerplate handlers. This function already handles:
- Detecting local vs remote paths via `ParseRemoteSource()`
- Auth token injection via `GetTokenForHost()` + `InjectGitToken()`
- Sparse checkout for subpaths (`//path` syntax)
- Temp directory creation with cleanup function
- Concurrency limiting via semaphore

**No frontend changes needed** — the `path` prop value is passed as `templatePath` to the API; the backend handles detection.

## Changes

### 1. Extract and rename shared remote resolution function

**File**: `api/tf_parse_handler.go`

- Rename `resolveRemoteSource()` → `resolveRemoteSource()` to reflect its generic purpose
- Rename `tfRemoteCloneSem` → `remoteCloneSem` (and update its references)
- This ensures TfModule and Template share a single concurrency limit (3 concurrent clones total), preventing resource exhaustion

### 2. Update `HandleBoilerplateRequest` (config endpoint)

**File**: `api/boilerplate_config.go`

In the `req.TemplatePath != ""` branch (lines ~102-131):
- Replace the manual `filepath.Join(runbookDir, templatePath)` + `os.Stat` logic with a call to `resolveModuleSource(req.TemplatePath, runbookPath)`
- Defer `cleanup()` if non-nil (handles temp dir removal for remote sources)
- After resolution, find `boilerplate.yml`/`boilerplate.yaml` within the resolved directory
- Set `templateDir` for output dependency scanning (works identically for local and cloned dirs)

### 3. Update `HandleBoilerplateRender` (render endpoint)

**File**: `api/boilerplate_render.go`

In `HandleBoilerplateRender` (lines ~126-140):
- Replace the manual `filepath.Join(runbookDir, req.TemplatePath)` + `os.Stat` logic with `resolveModuleSource(req.TemplatePath, runbookPath)`
- Defer `cleanup()` if non-nil
- Pass the resolved local path to `RenderBoilerplateTemplate()` as before

### 4. Update error messages

Use source-type-aware error messages:
- For local paths: `"Local template source not found at path: /abs/path/to/templates/vpc"`
- For remote URLs: `"Remote template source not found at: github.com/acme/templates//vpc?ref=v1.0"`
- For clone failures: `"Failed to clone remote template: <underlying error>"`
- For resolution failures: `"Failed to resolve template source: <underlying error>"`

## Files Modified

| File | Change |
|------|--------|
| `api/tf_parse_handler.go` | Rename `resolveModuleSource` → `resolveRemoteSource`, `tfRemoteCloneSem` → `remoteCloneSem` |
| `api/boilerplate_config.go` | Use `resolveRemoteSource()` for template path resolution |
| `api/boilerplate_render.go` | Use `resolveRemoteSource()` for template path resolution |

## Files NOT Modified

- Frontend (`web/src/components/mdx/Template/`) — path is passed through as-is
- `api/remote_source.go`, `api/git_clone.go`, `api/remote_token.go` — reused as-is
- `RenderBoilerplateTemplate()` — receives a local path regardless of original source

## Edge Cases

1. **Cleanup reliability**: `defer cleanup()` in the handler ensures temp dirs are removed on both success and error paths
2. **`boilerplate.yml` vs `.yaml`**: After resolving the source directory, check for both extensions
3. **Blob URLs**: `ParseRemoteSource` adjusts blob paths to parent directory — correct since we want the template directory
4. **Inline content path**: The `req.BoilerplateContent` branch in config handler is unaffected
5. **Output dependency scanning**: `extractOutputDependenciesFromTemplateDir` works on any local directory, including cloned temp dirs

## Verification

1. **Unit tests**: Build and run `go build ./...` and `go test ./api/...`
2. **Manual test with local path**: Ensure existing `<Template path="templates/foo">` still works
3. **Manual test with remote path**: Use a remote URL like `github.com/gruntwork-io/runbooks//testdata/sample-runbooks/my-first-runbook/templates/project?ref=main` as the template path