Problem

We are evaluating the Coder Premium plan primarily for the browser-only connection enforcement
to meet our DLP requirements. In this mode, users connect to workspaces exclusively through
browser-based IDEs like code-server.

However, we discovered that workspace app sessions (e.g., code-server accessed via the Coder
dashboard) do not trigger an activity bump on the workspace deadline. Only SSH, VS Code Remote,
JetBrains Gateway, and Web Terminal sessions currently bump the deadline.

This means that even while a user is actively editing code in code-server, the workspace will
auto-stop when the original deadline expires. Conversely, due to the legacy
ConnectionCount-based activity detection path (reporter.go:165), the agent's persistent
localhost connections to code-server can keep bumping the deadline indefinitely — even after the
user closes the browser tab.

The result is that auto-stop behaves unpredictably with code-server: it either never triggers
(because of background connections) or ignores genuine user activity.

Proposed Solution

ReportAppStats() in coderd/workspacestats/reporter.go currently updates last_used_at but does
not call ActivityBumpWorkspace(). Adding a deadline bump in this code path would allow workspace
apps to properly extend the workspace lifetime while in use.

The app stats pipeline already tracks session lifecycle via SessionStartedAt / SessionEndedAt
(set when the proxied connection closes in proxy.go), so closing the browser tab would naturally
stop generating new stats and allow the deadline to expire as expected.

This aligns with the TODO comment in reporter.go:24-39 about unifying the two activity reporting
paths (coder/internal#196).

Use Case

• DLP / security: Browser-only enforcement (Premium) restricts users to workspace apps like
  code-server
• Cost management: Auto-stop with activity-based deadline bumping is essential to avoid idle
  cloud compute costs
• Current workaround: max_deadline or scheduled auto-stop can be used, but these are blunt
  instruments that may interrupt active work or still leave idle workspaces running

These two Premium features — browser-only mode and activity-based auto-stop — should work well
together, as organizations that enforce browser-only access for security reasons also tend to
care about proper resource lifecycle management.