Merge pull request #36746 from dotnet/main

Author: guardrex

.github/agents/issue-triage-nonblazor.agent.md

@@ -67,7 +67,10 @@ If any content is not in English:
 ### File Naming
 `<issue-number>-analysis-report.md`
 
+Provide a link to the report file, an absolute link that can be clicked on from anywhere.
+
 ### Report Structure
+Eliminate duplicate report content that may arise from running the analysis more than one time on an issue.
 
 #### Header (REQUIRED - Always include this community-facing notice)
 ```markdown

aspnetcore/blazor/security/index.md

@@ -92,7 +92,7 @@ For more information, see the following resources:
 
 Server-side Blazor apps are configured for security in the same manner as ASP.NET Core apps. For more information, see the articles under <xref:security/index>.
 
-The authentication context is only established when the app starts, which is when the app first [connects to the WebSocket over a SignalR connection](xref:signalr/authn-and-authz) with the client. Authentication can be based on a cookie or some other bearer token, but authentication is managed via the SignalR hub and entirely within the [circuit](xref:blazor/hosting-models#blazor-server). The authentication context is maintained for the lifetime of the circuit. Apps periodically revalidate the user's authentication state every 30 minutes.
+The authentication context is only established when the app starts, which is when the app first [connects to the WebSocket over a SignalR connection](xref:signalr/authn-and-authz) with the client. Authentication can be based on a cookie or some other bearer token, but authentication is managed via the SignalR hub and entirely within the [circuit](xref:blazor/hosting-models#blazor-server). The authentication context is maintained for the lifetime of the connection and is re-evaluated on reconnection.
 
 If the app must capture users for custom services or react to updates to the user, see <xref:blazor/security/additional-scenarios#circuit-handler-to-capture-users-for-custom-services>.