[12.x] Fix Postgres sequence starting value for custom schemas/connections

[joteejotee]

Description

This PR fixes an issue where the from() / startingValue() method was ignored when using PostgreSQL with secondary database connections or custom schemas (Issue #58095).

The previous implementation manually constructed the sequence name string (e.g., {$table}_{$column}_seq), which fails if the actual sequence name differs due to schemas or connection configurations.

This PR updates the grammar to use the native pg_get_serial_sequence function, which correctly resolves the sequence name regardless of the schema or connection.

Fixed Issue

Fixes #58095

Verification

I have added unit tests to ensure the correct SQL is generated (select setval(...)).
I have also manually verified this against a running PostgreSQL container to confirm that the setval statement correctly sets the auto-increment starting value without errors.

[hafezdivandari]

Is the issue that this PR is trying to resolve actually reproducable? Would you please add a failing test?

I've added a test on #58117 which is working as expected.

Also, we have passing integration tests for custom schema names here:

framework/tests/Integration/Database/SchemaBuilderSchemaNameTest.php

Lines 543 to 557 in 4a56414

	#[DataProvider('connectionProvider')]
	#[RequiresDatabase(['mariadb', 'mysql', 'pgsql'])]
	public function testAutoIncrementStartingValue($connection)
	{
	$this->expectNotToPerformAssertions();
	$schema = Schema::connection($connection);
	$schema->create('my_schema.table', function (Blueprint $table) {
	$table->increments('code')->from(25);
	});
	$schema->create('table', function (Blueprint $table) {
	$table->increments('code')->from(15);
	});
	}

[joteejotee]

@hafezdivandari

Thanks for reviewing!

To be honest, I haven't added a failing test yet because reproducing a specific "secondary connection" issue within the integration test suite requires a somewhat complex setup compared to the fix itself.

However, the core issue is that the current implementation guesses the sequence name ({$table}_{$column}_seq), which is fragile when the actual sequence name differs (e.g., in custom schemas or secondary connections).

This PR simply replaces that guessing logic with pg_get_serial_sequence, which is the native and standard PostgreSQL way to resolve sequence names reliably.

Since @sandervankasteel (the reporter) offered to verify this fix in their environment today, I would like to wait for their feedback to confirm it solves the real-world issue.