sqlserver: `serverId` on Trigger and RealtimeTrigger is a documented no-op

## Summary

`io.kestra.plugin.debezium.sqlserver.Trigger` and `RealtimeTrigger` both declare and document a `serverId` property, but it is never read: it is not passed to `Capture.builder()`, and `sqlserver.Capture` has no `serverId` field at all. `server.id` is a MySQL-only Debezium concept. Users who set it get silent no-op behaviour on a property the UI and the generated docs present as functional.

Surfaced during the documentation review in #199, which deliberately left code changes out of scope.

## Actual Behaviour

Both SQL Server triggers expose the property:

- `plugin-debezium-sqlserver/src/main/java/io/kestra/plugin/debezium/sqlserver/Trigger.java:66` — `private String serverId;`
- `plugin-debezium-sqlserver/src/main/java/io/kestra/plugin/debezium/sqlserver/RealtimeTrigger.java:62` — `private String serverId;`

Neither `evaluate()` implementation passes it to the `Capture.builder()` chain, and `sqlserver/Capture.java` declares no matching field or `database.server.id` property. Setting `serverId` on a SQL Server trigger therefore changes nothing about the resulting connector configuration.

Two secondary problems on the same field:

1. It is a raw `String`, not `Property`, so it is not Pebble-renderable — unlike its MySQL counterpart (`mysql/Trigger.java:61`, `Property serverId`). New and existing properties should use `Property`.
2. It carries no `@PluginProperty(group = ...)`, so it renders ungrouped in the UI.

## Expected Behaviour

`serverId` should not appear on the SQL Server triggers at all. Removing it aligns the SQL Server module with `sqlserver.Capture`, which correctly has no such field.

If it was added deliberately for some SQL Server–specific purpose, it should instead be wired through to `Capture` as a `Property` with a `@Schema` explaining what it controls.

## Suggested Fix

Remove the field from both `sqlserver/Trigger.java` and `sqlserver/RealtimeTrigger.java`.

**Backward compatibility**: this is a user-visible property removal. Existing flows that set `serverId` on a SQL Server trigger will start failing deserialization instead of silently ignoring the value. Given that the property has never done anything, failing loudly is arguably correct — but confirm whether the plugin's compatibility policy requires a deprecation cycle (keep the field, mark `@Deprecated`, log a warning when non-null) before outright removal.

## Reproducer

```yaml
id: sqlserver_serverid_noop
namespace: company.team

tasks:
- id: log
type: io.kestra.plugin.core.log.Log
message: "{{ trigger.uris }}"

triggers:
- id: trigger
type: io.kestra.plugin.debezium.sqlserver.Trigger
snapshotMode: INITIAL
hostname: 127.0.0.1
port: "1433"
username: "{{ secret('SQLSERVER_USERNAME') }}"
password: "{{ secret('SQLSERVER_PASSWORD') }}"
database: deb
serverId: "123456789" # accepted, documented, and completely ignored
```

The flow validates and runs; `serverId` never reaches the Debezium connector properties.

## Logs / Stack Trace

No logs available — the failure mode is silence, not an error.

## Environment

- **Kestra version**: 1.3.16 (`kestraVersion` in `gradle.properties`)
- **Plugin version**: 1.4.7
- **Deployment**: n/a — source-level defect, reproducible on any deployment

## Acceptance Criteria

- [ ] `serverId` removed from `sqlserver/Trigger.java` and `sqlserver/RealtimeTrigger.java` (or wired through to `Capture` as a `Property` if it has a real purpose)
- [ ] A deprecation path is applied if the plugin's compatibility policy requires one
- [ ] Test coverage confirms a SQL Server trigger flow without `serverId` still runs the happy path
- [ ] No remaining `@Schema`/docs text referencing a SQL Server `serverId`

## Additional Context

Flagged in the review of #199 (documentation-only PR). Related: the MySQL `serverId` has its own set of problems, tracked separately.

---
*[View as Artifact](https://claude.ai/code/artifact/6acd8c87-11eb-4691-8ad0-6947cec4bbd6)*

Read sqlserver/Trigger.java, sqlserver/RealtimeTrigger.java, and sqlserver/Capture.java first, then check the plugin compatibility policy before choosing removal or deprecation. Locate and run the existing SQL Server trigger tests, and confirm the completed change leaves no SQL Server serverId schema or documentation references while preserving the trigger happy path.

Written by the indexing model from the issue text.