🐛 bug: Prevent app.init mutex deadlock on panic

[Copilot]

Description

app.init() manually released app.mutex, so a panic during service or view initialization could leave the app permanently locked. This change makes the init critical section panic-safe without changing the existing post-init hook registration order.

• Locking fix

  • Scope the app.init() critical section inside a small inner function.
  • Use defer app.mutex.Unlock() inside that scope so panics from initServices() or Views.Load() cannot strand the mutex.
  • Keep the existing behavior where OnPostShutdown is registered only after the init lock has been released.

• Regression coverage

  • Add a focused test that forces Views.Load() to panic during a follow-up app.init().
  • Verify a later app.Get(...) call does not block, covering the original deadlock path.

func (app *App) init() *App {
	func() {
		app.mutex.Lock()
		defer app.mutex.Unlock()

		app.initServices()
		if app.config.Views != nil {
			_ = app.config.Views.Load()
		}

		app.server = &fasthttp.Server{...}
	}()

	app.Hooks().OnPostShutdown(...)
	return app
}

Changes introduced

• Benchmarks: No benchmark changes.
• Documentation Update: No documentation changes.
• Changelog/What's New: Internal reliability fix for app initialization under panic.
• Migration Guide: No migration required.
• API Alignment with Express: Not applicable; no API surface change.
• API Longevity: Preserves existing behavior while hardening initialization against panic-induced deadlocks.
• Examples: Included a minimal code snippet showing the panic-safe locking structure.

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• Enhancement (improvement to existing features and functionality)
• Documentation update (changes to documentation)
• Performance improvement (non-breaking change which improves efficiency)
• Code consistency (non-breaking change which improves code reliability and robustness)

Checklist

Before you submit your pull request, please make sure you meet these requirements:

• Followed the inspiration of the Express.js framework for new functionalities, making them similar in usage.
• Conducted a self-review of the code and provided comments for complex or critical parts.
• Updated the documentation in the /docs/ directory for Fiber's documentation.
• Added or updated unit tests to validate the effectiveness of the changes or new features.
• Ensured that new and existing unit tests pass locally with the changes.
• Verified that any new dependencies are essential and have been agreed upon by the maintainers/community.
• Aimed for optimal performance with minimal allocations in the new code.
• Provided benchmarks for the new code to analyze and improve upon.

Commit formatting

Please use emojis in commit messages for an easy way to identify the purpose or intention of a commit. Check out the emoji cheatsheet here: CONTRIBUTING.md

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.38%. Comparing base (0290ca8) to head (4c69a78).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4366      +/-   ##
==========================================
+ Coverage   91.33%   91.38%   +0.04%     
==========================================
  Files         132      132              
  Lines       13104    13105       +1     
==========================================
+ Hits        11969    11976       +7     
+ Misses        716      711       -5     
+ Partials      419      418       -1     

Flag	Coverage Δ
unittests	91.38% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Hardens App.init() against panic-induced deadlocks by making the init mutex unlock panic-safe while preserving the existing ordering where OnPostShutdown is registered only after the init lock is released.

Changes:

• Scope the App.init() critical section in an inner function and use defer app.mutex.Unlock() to ensure the mutex is always released, even if initServices() or Views.Load() panics.
• Keep OnPostShutdown registration outside the critical section to preserve the prior lock-release ordering.
• Add a regression test that forces a panic during a second app.init() and verifies later route registration does not deadlock.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
app.go	Makes app.init() mutex unlock panic-safe by scoping the lock and deferring Unlock() within an inner function.
app_test.go	Adds a test that reproduces the prior deadlock scenario (panic during init()), asserting route registration proceeds afterward.