test(coderd): drain dormancy audit log before reset in StartWakesUpDormantWorkspace (#27541)

Closes PLAT-219 /
[coder/internal#1532](https://github.com/coder/internal/issues/1532).

The reported failure (`should have 2 item(s), but has 3`) was the stop
build's outcome audit landing after `auditor.ResetLogs()`; that path was
already deflaked by #26232 and the pre-reset drain added in #25037.

This closes the remaining hole in the same class: the dormancy update's
audit log is exported in a middleware `defer` after the API response, so
it can also land after `ResetLogs` and break the exact `len == 2`
assertion. Extend the pre-reset poll to drain the dormancy write entry
alongside the stop build entry.

Verified with `go test ./coderd -run TestWorkspaceDormant -count=5` and
`-race`.

> Generated by Coder Agents on behalf of @Emyrk.

coderd/workspaces_test.go

@@ -4922,8 +4922,17 @@ func TestWorkspaceDormant(t *testing.T) {
 
 		// Should be able to stop a workspace while it is dormant.
 		workspace = coderdtest.MustTransitionWorkspace(t, client, workspace.ID, codersdk.WorkspaceTransitionStart, codersdk.WorkspaceTransitionStop)
+		// Drain both audit entries emitted so far (the dormancy update and
+		// the stop build) before resetting the auditor. Audit logs are
+		// exported asynchronously relative to the API responses, so an entry
+		// landing after ResetLogs would break the exact count assertion
+		// below.
 		testutil.Eventually(ctx, t, func(context.Context) bool {
 			return auditor.Contains(t, database.AuditLog{
+				ResourceID:   workspace.ID,
+				ResourceType: database.ResourceTypeWorkspace,
+				Action:       database.AuditActionWrite,
+			}) && auditor.Contains(t, database.AuditLog{
 				ResourceID:   workspace.LatestBuild.ID,
 				ResourceType: database.ResourceTypeWorkspaceBuild,
 				Action:       database.AuditActionStop,