[princejain756]

Fixes #1199

The GHSA-pvrx-3g7m-fpgv containment check in SpringTemplateLoader.getResource rejects legitimate classpath: prefixed templates on 4.5.5. Two failure modes, both reported in the issue:

• Exploded classpath (IDE, target/classes): the base directory was computed as new File("/templates/"), a filesystem-root path, while the resolved resource lives under .../target/classes/templates/. The startsWith check could never succeed.
• Inside a JAR: url.getPath() returns the full nested:/jar: path including the archive location, compared against /templates/ prefix. Same guaranteed failure.

Changes:

• File resources now compare against the prefix resolved through the Spring ResourceLoader (loader.getResource(getPrefix())), so classpath:/templates/ maps to the real classpath directory instead of the filesystem root. When the prefix has no file-resolvable resource, the previous literal-strip behavior is kept as fallback, so file: prefixes keep identical semantics.
• Non-file resources (jar/nested/vfs URLs) now compare the innermost archive entry path, the segment after the last !, against the normalized prefix via contains. The classpath URL namespace cannot produce percent-decoded traversal anyway (the class loader does not decode resource names), so containment stays meaningful while legitimate entries pass.

Tests: two new cases in SpringTemplateLoaderTest, both red on master and green here: classpath:/templates/ resolving an exploded classpath resource via a real DefaultResourceLoader, and a mocked jar:file: entry URL. The existing traversal, fragment, query, and percent-encoding tests all still pass (10/10 in the module).