Please address the comments from this code review:

## Overall Comments
- In `buildInitViewModel`, `st.TargetSkillCombinations` is accessed before the `st == nil` guard, which will panic if the function is called with a nil `RunState`; move the nil check to the very top before any field access.
- `runUnifiedSkillDecision` assumes `engine` is non-nil and calls `engine.MatchOCR` unconditionally; consider either asserting this precondition explicitly (e.g., early return with a focus error) or guarding against a nil engine to avoid potential panics if it is ever invoked with a nil engine in new call sites.

## Individual Comments

### Comment 1
<location path="agent/go-service/essencefilter/integration.go" line_range="104-105" />
<code_context>
+	SlotSkills      [3][]string
+}
+
+func buildInitViewModel(st *RunState) InitViewModel {
+	vm := InitViewModel{
+		FilteredWeapons: make([]matchapi.WeaponData, 0, len(st.TargetSkillCombinations)),
+	}
</code_context>
<issue_to_address>
**issue (bug_risk):** Potential nil pointer dereference when `st` is nil in `buildInitViewModel`

`len(st.TargetSkillCombinations)` is evaluated before checking `st == nil`, so this will panic if `buildInitViewModel` is ever called with a nil `RunState`. Please guard `st == nil` first and only use `st.TargetSkillCombinations` when `st` is confirmed non-nil.
</issue_to_address>

### Comment 2
<location path="agent/go-service/essencefilter/actionsAfterBattle.go" line_range="27" />
<code_context>
 	}
-	skills := []string{ocr.Skills[0], ocr.Skills[1], ocr.Skills[2]}

 	if st.MatchEngine == nil {
+		reportFocusByKey(ctx, st, "focus.error.no_match_engine")
 		return false
</code_context>
<issue_to_address>
**question:** After-battle decision now hard-depends on `st.MatchEngine` and no longer falls back to defaults

This now errors when `st.MatchEngine` is nil and assumes `PipelineOpts` was set up earlier, instead of reconstructing options or falling back to `defaultEssenceFilterOptions()`. That tightens the pipeline contract: any flow calling `EssenceFilterAfterBattleSkillDecisionAction` without a prior init that sets `st.MatchEngine` will fail instead of using defaults. If that behavior is desired, please verify all after-battle pipeline JSONs always run the init step first; otherwise consider calling `EnsureMatchEngine` here or restoring a minimal fallback for missing state.
</issue_to_address>