[fix][evaluation] guard nil BaseInfo and nil correction to prevent panics in experiment result and record correction paths

[xueyizheng]

What type of PR is this?
fix
Check the PR title
[x] This PR title match the format: [][]
[x] The description of this PR title is user-oriented and clear enough for others to understand.
[ ] Add documentation if the current PR requires user awareness at the usage level.
[x] This PR is written in English. PRs not in English will not be reviewed.
(Optional) More detailed description for this PR
Fixes two independent nil pointer dereferences in the evaluation module. Both follow the same shape: a pointer field is dereferenced before it is checked, so a single record or request with a missing optional field takes down the whole call instead of degrading gracefully.

1. EvalTargetRecordDO2DTO dereferences src.BaseInfo unconditionally
   The DTO is built with CreatedAt: src.BaseInfo.CreatedAt inside the struct literal. The if src.BaseInfo != nil check below it is dead as a guard, because the dereference already happened while evaluating the literal.
   BaseInfo is an optional field on EvalTargetRecord, so any record that has it unset panics the conversion. Since this convertor runs in the fan-out of BatchGetExperimentResult, one such record fails the entire batch rather than just its own row, and the caller sees a 5xx instead of partial results.
   Fix: initialize an empty BaseInfo in the literal and populate the timestamps inside the existing nil check. The CreatedBy / UpdatedBy TODOs move with them, so they are guarded too when someone eventually fills them in.
2. CorrectEvaluatorRecord dereferences correctionDO on its first line
   EvaluatorRecordServiceImpl.CorrectEvaluatorRecord starts with correctionDO.UpdatedBy = userIDInContext, before any validation. The method already defensively initializes EvaluatorOutputData, EvaluatorResult and BaseInfo a few lines further down, so the intent is clearly to tolerate a sparsely populated record — the correction argument was simply missed.
   Correction is optional in the request, and OpenAPICorrectionDTO2DO returns nil for a nil DTO by design. So a CorrectEvaluatorRecordOApi call that omits correction reaches the domain service with correctionDO == nil and panics on a caller mistake that should have been a 4xx.
   Fix, at two levels:
   domain service: reject nil evaluatorRecordDO / correctionDO with
   CommonInvalidParamCode before touching either.
   OpenAPI handler: validate req.Correction up front, so a malformed request
   gets a structured invalid-param error and never reaches the domain layer.
   Tests
   Three regression tests, one per guarded entry point:
   TestEvalTargetRecordDO2DTO_NilBaseInfo — a record with BaseInfo: nil
   converts without panicking and yields a non-nil, empty BaseInfo.
   TestEvaluatorRecordServiceImpl_CorrectEvaluatorRecord_NilParams — all three
   nil combinations return an error, and the repo / publisher mocks assert
   Times(0) so validation is proven to run before any side effect.
   eval_openapi_app_test.go gains a nil correction case asserting
   CommonInvalidParamCode with auth and the record service never invoked.
   Each test was checked against the unpatched code and fails there with invalid memory address or nil pointer dereference, so they pin the actual defect rather than passing vacuously.
   Two pre-existing cases in TestEvalOpenAPIApplication_CorrectEvaluatorRecordOApi (record not found, auth failed) omitted Correction and are now short-circuited by the new up-front check. They were given a valid correction so they still exercise their intended paths.
   Note for reviewers: these packages need -gcflags="all=-N -l" (required by mockey); without it unrelated cases fail their own self-check.