feat: add capabilities to keyring endowment

[hmalik88]

Adding capabilities to the keyring endowment as part of keyring v2 work (https://github.com/MetaMask/decisions/blob/main/decisions/core/0006-keyring-interface.md)

---

Note

Medium Risk
Extends the endowment:keyring permission model and manifest validation with a new optional caveat; mistakes could cause snaps’ permissions/manifests to be rejected or misinterpreted across clients.

Overview
Adds a new keyringCapabilities caveat to endowment:keyring, allowing snaps to declare supported keyring capabilities (e.g., scopes and optional BIP-44/private key/custom flags) in initialPermissions/manifests.

Updates the keyring endowment permission spec to accept/validate this optional caveat, adds getKeyringCaveatCapabilities, and adjusts the caveat mapper to emit origin + capabilities caveats (or null when empty). Propagates the new caveat through SDK permission types, snaps-utils caveat enum + runtime struct/assertion + manifest validation, and updates tests/snapshots/coverage thresholds accordingly.

^{Reviewed by Cursor Bugbot for commit e629c04. Bugbot is set up for automated code reviews on this repo. Configure here.}

[socket-security]

No dependency changes detected. Learn more about Socket for GitHub.

👍 No dependency changes detected in pull request

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.56%. Comparing base (26ff2aa) to head (e629c04).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3903   +/-   ##
=======================================
  Coverage   98.56%   98.56%           
=======================================
  Files         426      427    +1     
  Lines       12316    12343   +27     
  Branches     1935     1939    +4     
=======================================
+ Hits        12139    12166   +27     
  Misses        177      177           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[FrederikBolding]

Did we decide on behaviour if this is not defined? Since we are making it optional

[hmalik88]

Yes, omission of the capabilities is an implicit indication of using keyring v1

[GuillaumeRx]

There's probably a better way of doing this that doesn't require the ugly type cast at the end

[hmalik88]

Hmm, I followed the pattern Frederik suggested: #3903 (comment)

[GuillaumeRx]

You can do that to remove the need to cast to unkown :

Suggested change

	const caveats = [];
	caveats.push({
	type: SnapCaveatType.KeyringOrigin,
	value: { allowedOrigins: value.allowedOrigins },
	});
	if (hasProperty(value, 'capabilities')) {
	caveats.push({
	type: SnapCaveatType.KeyringCapabilities,
	value: { capabilities: value.capabilities },
	});
	}
	return { caveats: caveats as unknown as NonEmptyArray<CaveatConstraint> };
	const caveats = [];
	caveats.push({
	type: SnapCaveatType.KeyringOrigin,
	value,
	});
	if (value.capabilities) {
	caveats.push({
	type: SnapCaveatType.KeyringCapabilities,
	value,
	});
	}
	return { caveats: caveats as NonEmptyArray<CaveatConstraint> };

Also I've noticed in Frederik's example that the value is extracted so I don't know if we should do that instead :

Suggested change

	const caveats = [];
	caveats.push({
	type: SnapCaveatType.KeyringOrigin,
	value: { allowedOrigins: value.allowedOrigins },
	});
	if (hasProperty(value, 'capabilities')) {
	caveats.push({
	type: SnapCaveatType.KeyringCapabilities,
	value: { capabilities: value.capabilities },
	});
	}
	return { caveats: caveats as unknown as NonEmptyArray<CaveatConstraint> };
	const caveats = [];
	caveats.push({
	type: SnapCaveatType.KeyringOrigin,
	value: value.allowedOrigins,
	});
	if (value.capabilities) {
	caveats.push({
	type: SnapCaveatType.KeyringCapabilities,
	value: value.capabilities,
	});
	}
	return { caveats: caveats as NonEmptyArray<CaveatConstraint> };

Both works TBH, I'm just wondering why there's a difference between the two

[GuillaumeRx]

The second one seems to be the standard btw

[hmalik88]

Undid extracting the value since it seems we weren't doing that with allowedOrigins before so I'll still follow that pattern. I did however get the unknown cast removed.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}