fix: convert JS template expressions to glob wildcards in pattern mat…

[hiro05097952]

Summary

• resolvePattern preserved ${...} template literal syntax verbatim, but Go's path.Match doesn't recognize JS template expressions — causing dynamic references like new URL(`./images/${code}.webp`, import.meta.url) to never match sibling assets
• Added templateExprRe to replace ${...} with * glob wildcards before matching, so ./images/${code}.webp becomes ./images/*.webp
• Added test covering template literal pattern resolution with multiple assets

Problem

Files referenced via JS template literals were incorrectly reported as unused:

function getIcon(name: string) {
  return new URL(`./icons/${name}.webp`, import.meta.url).href
}

Extract() correctly identified this as a pattern kind, but resolvePattern() passed ${category} through to globMatchRepoPath(), where path.Match("${category}.webp", "apple.webp") returned false.

Test plan

• go test ./internal/references/ -run TestBuildMapResolvesTemplateLiteralPattern -v — PASS
• go test ./internal/references/ -v — all existing tests still pass

[gemini-code-assist]

Code Review

This pull request introduces support for resolving template literal patterns (e.g., ${code}) in asset references by replacing them with a wildcard * before resolving aliases. A new regular expression templateExprRe is added to match these expressions, and a corresponding unit test is introduced to verify the resolution of template literal patterns. There are no review comments, and I have no additional feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.