Interactions: Accept webfinger IDs

[obenland]

Fixes #1831.
Introduced in #1149.

Proposed changes:

• Replaces uri formatting from uri parameter with sanitization callback.
• Adds unit test for accepting webfinger IDs.

Other information:

• Have you written new tests for your changes, if applicable?

Testing instructions:

• When following the Steps to reproduce in Interactions REST API not compatible with Mastodon-style / Webfinger usernames #1831, make sure the request fails with This Interaction type is not supported yet! and not with The URL is not supported!.

Changelog entry

• Automatically create a changelog entry from the details below.

Changelog Entry Details

Significance

• Patch
• Minor
• Major

Type

• Added - for new features
• Changed - for changes in existing functionality
• Deprecated - for soon-to-be removed features
• Removed - for now removed features
• Fixed - for any bug fixes
• Security - in case of vulnerabilities

Message

Interaction attempts that pass a webfinger ID instead of a URL will work again.

[Copilot]

Pull Request Overview

This PR enables the interactions endpoint to accept Webfinger IDs (e.g., user@domain) in addition to URLs by adding a sanitization callback, updating the route schema, and covering the new behavior with a unit test.

• Introduce sanitize_uri() to trim leading “@” and choose between email or URL sanitizers.
• Update uri argument description and remove the strict URI format check.
• Add a REST endpoint test that uses a Webfinger ID and expects the appropriate exception.

Comments suppressed due to low confidence (2)

tests/includes/rest/class-test-interaction-controller.php:129

• The test expects an exception message but doesn’t specify the exception class. Add $this->expectException(\WP_REST_Exception::class); before this line to ensure the exception is properly caught.

		$this->expectExceptionMessage( 'This Interaction type is not supported yet!' );

tests/includes/rest/class-test-interaction-controller.php:127

• [nitpick] Consider adding direct unit tests for sanitize_uri() itself to cover inputs like leading '@', pure URLs, invalid emails, and 'acct:' prefixes, rather than relying only on dispatch behavior.

		$request->set_param( 'uri', 'activitypub.blog@activitypub.blog' );