Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/persis/fileproc/procgrp.go`:
- Around line 198-229: The scan currently fails if a DAG directory or proc file
disappears mid-walk; update the loops around os.ReadDir(dagDir) and the call to
readProcEntry(file, pg.groupName, pg.staleTime, now) to treat missing-file/dir
errors as non-fatal: when os.ReadDir(dagDir) returns an error, if errors.Is(err,
fs.ErrNotExist) (or os.IsNotExist(err)) then continue to the next dagEntry
instead of returning the error; similarly, when readProcEntry returns an error,
if it indicates ENOENT (errors.Is(err, fs.ErrNotExist) / os.IsNotExist(err))
just skip that file and continue, otherwise return the error—this yields a
best-effort scan used by ListAllAlive and zombie detection while still surfacing
real errors.

In `@internal/runtime/manager_test.go`:
- Around line 369-377: The handler currently calls w.WriteHeader(http.StatusOK)
before json.Marshal, causing a second
WriteHeader(http.StatusInternalServerError) to be ignored; change the order in
the anonymous http handler so that you call json.Marshal(status) first, handle
marshalErr (write a 500 response and return) and only after successful
marshaling call w.WriteHeader(http.StatusOK) and w.Write(jsonData); reference
the existing json.Marshal(status), w.WriteHeader, and w.Write calls to locate
and reorder the logic.

In `@internal/test/helper.go`:
- Around line 753-760: Replace the hardcoded AttemptID ("attempt_"+a.dagRunID)
used when calling a.ProcStore.Acquire with the production-consistent format:
call the same generator used in production (genAttemptID()) or replicate it by
hex-encoding 3 random bytes to produce a 6-character hex string, and use that
value for AttemptID; if the test intentionally uses the synthetic format, add a
one-line comment next to AttemptID explaining why the simplified value is used
and that it intentionally diverges from genAttemptID().

---

Outside diff comments:
In `@internal/service/scheduler/zombie_detector_test.go`:
- Around line 327-444: The mockProcStore currently uses hasExpectedCall to
short-circuit and return zero values instead of delegating to testify/mock,
which hides unexpected calls; update mockProcStore methods (e.g., RemoveIfStale,
IsAttemptAlive, IsRunAlive, ListAlive, ListEntries, LatestFreshEntryByDAGName,
ListAllEntries, Acquire, CountAlive, CountAliveByDAGName, ListAllAlive) to
always call m.Called(...) and return its results so testify can assert
unexpected calls, and in tests mark optional interactions with .Maybe() or set
explicit expectations with .Once() (or use AssertNotCalled) for methods that
must not be invoked by detectAndCleanZombies. Ensure hasExpectedCall is removed
or only used to toggle deliberate optional behavior but does not suppress
m.Called(...) invocations.

---

Nitpick comments:
In `@internal/persis/fileproc/handle.go`:
- Around line 177-178: readProcEntry currently treats any undersized file as a
generic "too short" error but writeHeartbeat updates only the 8-byte timestamp
leaving JSON metadata after offset 8, so add a length-aware check in
readProcEntry to distinguish three cases: file length < 8 (no timestamp), file
length >= 8 but < expectedHeader+metadataStart (timestamp present but metadata
truncated), and full length OK; update the error messages accordingly to report
"no timestamp (file too short)", "timestamp present but metadata truncated", or
the existing parse error, and apply the same length-differentiated
checks/messages to the other read path referenced around the second block (the
code handling the alternate read at the other site) so corruption vs empty-file
cases are clear.

In `@internal/persis/fileproc/procfile.go`:
- Around line 199-202: The freshness check currently sets fresh based on
now.Sub(info.ModTime()) < staleTime and then rechecks using heartbeatTime if
modTime is stale; add a concise inline comment above these lines (referencing
fresh, info.ModTime(), heartbeatTime, staleTime) explaining that both modTime
and heartbeatTime are checked because filesystem modTime may lag behind
application heartbeats, so a recent heartbeat should mark the entry fresh even
if the file mtime appears stale; keep the comment short and focused on the
defensive rationale for future maintainers.