fix: don't add content script entry to web_accessible_resources when no loader is emitted

[Toumash]

Summary

• Don't add simple content script entries to web_accessible_resources when no loader is emitted (i.e., scripts with no imports, exports, or dynamic imports)
• These scripts are listed directly in content_scripts[].js and injected by Chrome itself — they don't need web_accessible_resources and exposing them is a minor security concern (fingerprinting)
• Per Chrome docs: "Content scripts themselves do not need to be allowed."

What changed

plugin-webAccessibleResources.ts: Changed the condition at the WAR generation step to only add the entry file when loaderName is set on the content script (meaning a loader was actually emitted and uses chrome.runtime.getURL() to fetch the entry):

- if (type === 'loader' || isDynamicScript)
+ const script = contentScripts.get(key)!
+ const hasLoader = !!script.loaderName
+ if ((type === 'loader' && hasLoader) || isDynamicScript)

Scripts with a loader still work correctly — the loader uses chrome.runtime.getURL() to dynamically import the real entry, so it must remain in WAR.

Tests

• Added e2e test (mv3-content-script-no-war-entry) that builds a simple content script extension, loads it in Chromium, verifies the content script executes correctly, and asserts the entry is NOT in web_accessible_resources
• Updated 14 snapshot tests that previously included the unnecessary WAR entries

Closes #1130

[changeset-bot]

⚠️ No Changeset found

Latest commit: a853867

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR