Harden VS Code activity reporting: use the *_last_activity settings seam instead of /api/contents/

[tylerpotts]

Context

#226 makes the bundled nebari-activity-reporter VS Code extension report user interaction by pinging GET /api/contents/?content=0 with the pod's API token. That advances jupyter-server's api_last_activity, which is what singleuserCuller.server.shutdownNoActivityTimeout evaluates.

Problem

The contents ping works by omission: upstream jupyter_server simply has not set _track_activity = False on the contents handler, while it has excluded other read-only endpoints (/api/status, /api/) and that flag has trended toward covering more of them. If a future jupyter_server release opts /api/contents/ out of activity tracking, the reporter's pings silently stop counting and actively-working VS Code users cull at shutdownNoActivityTimeout.

Raised by @viniciusdc in #226 (comment) (last point).

Current guard

The e2e test test_contents_api_ping_counts_as_activity (tests/e2e/test_vscode_idle_culling.py) pins the current contract and will fail on the image bump that pulls in a breaking jupyter_server, so the breakage is loud, not silent. But the fix at that point is this issue.

Proposed fix

Use the documented extension seam instead of the omission: jupyter-server's last_activity() folds in any settings key ending in _last_activity and calls it a hook for extensions.

• Ship a small jupyter server extension in the singleuser image exposing an authenticated endpoint (e.g. POST /api/nebari/activity) whose handler sets self.settings["vscode_last_activity"] = utcnow().
• Retarget the reporter extension's ping from /api/contents/?content=0 to the new endpoint.
• Update the e2e test to assert the new endpoint advances last_activity, keeping the contents-ping test until the reporter no longer uses it.

This removes the dependency on upstream _track_activity defaults entirely.