fix(access): Correct email access pages and sign-in links

[nfebe]

Use the existing FlatRun logo and product styles on access pages. Require confirmation before consuming sign-in links. Requests rejected by the configured access policy now show access denied instead of a check-your-email confirmation; these requests already sent no email. Both allowlist access and verification for any email remain available. Bump to 0.4.0-beta.11.

[sourceant]

Code Review Summary

Protected access requests now require the submitted email to match the deployment allowlist; unmatched addresses receive a branded 403 page before any sign-in email is sent. Sign-in links are inspected without being consumed, so users must confirm via POST before the token is consumed and a session issued. Access pages use an embedded FlatRun logo and product styles, and the version is bumped to 0.4.0-beta.11.

🚀 Key Improvements

• Unlisted emails are denied with a 403 page instead of silently receiving sign-in emails.
• Magic links split into InspectMagicLink and VerifyMagicLink so confirmation precedes token consumption (internal/access/service.go).
• Verification previews set no-store and no-referrer headers and embed the FlatRun logo.

💡 Minor Suggestions

• The resolution-time guard that forced allowlist mode for WordPress deployments was dropped, so a WordPress path saved with any_verified now lets any address that completes a sign-in link reach wp-login.php/wp-admin. Restore the forced mode (or reject any_verified for WordPress at config time) so protected paths require the FlatRun allowlist.
• Dropping the metadata parameter here removes the config-time check that rejected non-allowlist modes for WordPress deployments, so POST /deployments/:name/domains and PUT .../metadata can now persist any_verified on a WordPress path. Re-add the metadata argument and the wordpress + non-allowlist rejection so the requirement is enforced when policies are saved.

[sourceant]

Review complete. See the overview comment for a summary.

[sourceant]

internal/access/service.go

The resolution-time guard that forced allowlist mode for WordPress deployments was dropped, so a WordPress path saved with any_verified now lets any address that completes a sign-in link reach wp-login.php/wp-admin. Restore the forced mode (or reject any_verified for WordPress at config time) so protected paths require the FlatRun allowlist.

Suggested replacement:

			copy := *domain.Access
			if strings.EqualFold(deployments[i].Metadata.Type, "wordpress") {
				copy.Mode = "allowlist"
			}
			best = &copy

internal/api/deployment_actions.go

Dropping the metadata parameter here removes the config-time check that rejected non-allowlist modes for WordPress deployments, so POST /deployments/:name/domains and PUT .../metadata can now persist any_verified on a WordPress path. Re-add the metadata argument and the wordpress + non-allowlist rejection so the requirement is enforced when policies are saved.