validate: do not treat a remote-URL source as a missing local directory

[deanrie]

Summary

Fixes #640. schemas/marketplace.schema.json documents pluginEntry.source as "Path to the plugin directory (relative to the marketplace root) or a remote URL", but scripts/validate-plugins.mjs resolved every source as a path, so an entry with "source": "https://github.com/user/plugin" became <root>/https:/github.com/user/plugin and failed with source directory "https://..." does not exist. A schema-valid marketplace could not pass the repo's own validator, with a misleading message.

Remote sources are now skipped with an explicit INFO: ... remote source "..." is not validated locally line and the entry still goes through the marketplace schema check. Nothing fetches them; this only stops reporting a URL as a missing directory. The official marketplace in this repo has no remote sources, so the output on main is unchanged.

Kept separate from #618 so that PR does not grow after opening; the two touch different parts of the loop and apply in either order.

Verification

• node scripts/validate-plugins.mjs on main: All plugins validated successfully. (unchanged).
• With a planted {"name":"zz-remote","source":"https://github.com/user/zz-remote"} entry: one INFO line, run stays green; on main the same entry fails the run.

[rahul05ranjan]

Verified against the repo tree by replicating the loop's mechanics in a standalone script against the real marketplace.json (I don't have ajv available locally, so the schema side was checked against the schema definition itself rather than via ajv):

• Reproduced the reported failure mode: path.resolve(root, "https://github.com/user/plugin") returns <root>/https:/github.com/user/plugin, existsSync is false, so the old code fails with exactly the misleading source directory "..." does not exist message from #640. Also confirmed pluginEntry.source in schemas/marketplace.schema.json is just a non-empty string whose description permits a remote URL, so such an entry is schema-valid — the validator/schema mismatch is real.
• Old vs new loop logic on the actual marketplace with a planted {"name":"zz-remote","source":"https://github.com/user/plugin"} entry: old → 1 error; new → the INFO line and zero errors. The current marketplace (104 entries, no http sources) produces zero errors under both, so main output is indeed unchanged.
• The continue is placed correctly: it skips before the directory/plugin.json checks but leaves the marketplace schema validation path untouched.

One nit: /^https?:\/\// is case-sensitive, but URL schemes are case-insensitive per RFC 3986 — HTTPS://github.com/x/y would still fall through to resolve() and hit the old misleading error. (ftp:// sources have the same problem, though scoping to http(s) is reasonable given the marketplace's actual usage.)

[deanrie]

Hey @rahul05ranjan, thanks for running it against the real tree. Good catch on the scheme case: pushed 8680616, the test is now /^https?:\/\//i, so HTTPS://... takes the same path. Kept the scope at http(s); nothing in the marketplace or the schema description suggests other schemes, and if one shows up it should get its own explicit handling rather than a silent skip.