docs: add v1.17.4 and v1.18.1 upgrade notes

[goravel-coder]

Summary

• Add v1.17.4 / v1.18.1 upgrade notes to the English, 简体中文, and uz_UZ docs, covering two bug fixes shipped in this release pair.
• Describe the 🐛 [Bug] Two consecutive migrations with the same non-default Connection() write the second ledger row to the wrong database goravel#987 fix from the real user issue instead of internal code mechanics: two or more migrations in the same batch that return the same non-default connection from Connection() used to record the second migration's ledger row on that connection and fail with a table doesn't exist error — the note now explains that each migration still runs on its declared connection while its ledger row is recorded on the default connection, matching Laravel's behavior.
• Document that the Gin and Fiber drivers now compile the default template set lazily on the first serve call instead of when the route engine is built, so package views registered via View.LoadViewsFrom() in a provider's Boot() are picked up and render correctly (View.LoadViewsFrom() has no effect — gin driver compiles templates before the provider Boot phase goravel#989).

Why

These upgrade notes record two patch releases, v1.17.4 and v1.18.1, that ship two user-facing bug fixes. The note for goravel/goravel#987 (goravel/framework#1544 and goravel/framework#1545) was originally written from the perspective of the internal code change and has been rewritten to describe the real user issue. When two or more migrations in the same batch declare the same non-default connection, the second migration's ledger row was recorded on that connection instead of the default one, so the migration failed with a table doesn't exist error because no migrations table existed on the non-default connection:

package migrations

// M20260826160940CreateUsersTable runs on the non-default "mysql" connection.
func (r *M20260826160940CreateUsersTable) Connection() string {
	return "mysql"
}

// M20260826161140CreateUserTokensTable declares the same non-default connection.
func (r *M20260826161140CreateUserTokensTable) Connection() string {
	return "mysql"
}

After the fix each migration still runs on its declared connection, while its ledger row is recorded on the default connection — matching Laravel's behavior — so the migration batch completes without the table doesn't exist failure.

The same releases also fix goravel/goravel#989 in the Gin and Fiber drivers (goravel/gin#243 and goravel/fiber#297): the default template set used to be compiled when the route engine was built — before service providers boot — so views registered through LoadViewsFrom() in a provider's Boot() were missing from the compiled set:

// In an extension package's service_provider.go
func (r *ServiceProvider) Boot(app foundation.Application) {
	facades.View().LoadViewsFrom("/path/to/package/views")
}

Rendering those package views at request time previously failed. The drivers now compile the default template set lazily on the first serve call (Run/Listen/ServeHTTP), after all providers have booted, so LoadViewsFrom()-registered views are rendered correctly.

[hwbrzzl]

You described this issue based on the actual code, but I want you to describe this based on the real user issue.

[hwbrzzl]

ditto