fix(lifecycle): re-spawn boot loop on dormant reload

[couragehong]

Summary

Two coupled changes around the boot-loop reload path that /rune:configure depends on after a fresh install — without these, a freshly-spawned MCP server can't pick up a populated ~/.rune/config.json short of a Claude Code restart.

1. lifecycle.Manager 에 SetReloadFunc + Retrigger 추가
2. service.LifecycleService.ReloadPipelines 가 dormant 시 Retrigger + state polling
3. cmd/rune-mcp/main.go 가 SetReloadFunc 등록 + RunBootLoop 3-arg signature 호출 정정

End-to-end 효과: /rune:configure 처음 실행 후 Claude restart 없이 그대로 Active 도달.

Why

Boot loop returns after a terminal Dormant exit (config missing, state != "active", vault endpoint/token empty). Before this change LifecycleService.ReloadPipelines only reported state — it didn't actually re-trigger anything, so the goroutine stayed exited and the new config sat ignored.

/rune:configure 가 user input 받아 ~/.rune/config.json 작성 후 reload_pipelines 호출하는 정상 흐름이 결국 "restart 한 번 더 하세요" 로 끝났던 이유.

What changed

Manager.SetReloadFunc(f func()) — main.go 가 startup 시 한 번 등록.

Manager.Retrigger() — service 가 호출. state == Dormant 일 때만 callback 실행 (= fresh RunBootLoop goroutine spawn).

func (m *Manager) Retrigger() {
    if m.Current() != StateDormant {
        return  // 기존 goroutine 가 retry/active 중. respawn 하면 race.
    }
    // ... callback 실행
}

ReloadPipelines 가 dormant 시 Retrigger 후 폴링:

if s.State.Current() == lifecycle.StateDormant {
    s.State.Retrigger()
    s.waitForBootProgress(ctx, 5*time.Second)
}

waitForBootProgress 의 150ms 초기 grace — Retrigger 가 go RunBootLoop(...) 라 첫 read 가 prior Dormant 를 볼 가능성 회피.

main.go:

deps.State.SetReloadFunc(func() {
    go lifecycle.RunBootLoop(ctx, deps.State, deps)
})
go lifecycle.RunBootLoop(ctx, deps.State, deps)

직전 base 의 RunBootLoop(ctx, deps.State) 2-arg call 도 같이 정정 (3-arg signature 와 mismatch — base 가 build 안 됐던 상태).