next/font/local: square brackets in the font file name make the preload URL differ from the @font-face URL

A variable font copied as-is from the google/fonts repository keeps its axis tag in the file name (e.g. Family[wght].ttf). Loaded with next/font/local, Next emits a <link rel=preload> whose href percent-encodes the brackets (%5B...%5D) while the generated @font-face src keeps raw brackets. The browser treats them as two different URLs: the font downloads twice and Chrome logs on every page "The resource ... was preloaded using link preload but not used within a few seconds from the window's load event".

Rename the file without brackets (Google Fonts' own download archive uses Family-VariableFont_wght.ttf for the same file) and point localFont({ src }) at it. Keep the original name in a comment and keep the OFL license next to it. Verify with performance.getEntriesByType("resource"): the .ttf must appear once (initiator "link"), and no preload warning after ~4 s on load.

The WHATWG URL path percent-encode set does not include [ and ], so url(../media/Family[wght]-x.ttf) in CSS stays raw, while the preload href (and Link header) is emitted already encoded; the HTTP cache key differs.