Claude review: drm/i915/display/dp: Adopt dp_connector helpers to expose link training state

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Bug -- uninitialized stack struct in `intel_dp_report_link_train()`:**
```c
struct drm_connector_dp_link_train dp_link_train;

dp_link_train.rate = intel_dp->link_rate;
dp_link_train.nlanes = intel_dp->lane_count;
dp_link_train.dsc_en = connector->dp.dsc_decompression_enabled;

for (int i = 0; i < intel_dp->lane_count; i++) {
    ...
}
```
If `lane_count < 4`, the `v_swing[]` and `pre_emph[]` entries for unused lanes contain stack garbage, which will be written to the corresponding properties (since properties exist for all lanes up to the max). Should be `struct drm_connector_dp_link_train dp_link_train = {};`.

**Bug -- `drmm_connector_dp_init()` return value not checked:**
```c
drmm_connector_dp_init(dev, &connector->base, &intel_dp_connector_funcs,
                       &link_caps, type, &intel_dp->aux.ddc);
```
The return value is silently dropped. If property creation fails (OOM), the connector is initialized but without DP properties, leading to NULL pointer dereferences when `drm_connector_dp_set_link_train_properties()` tries to update them. Must check and handle this error.

**Concern -- DSC hardcoded true:**
```c
link_caps.dsc = true;
```
Not all i915 platforms support DSC. This should check actual platform DSC capability, otherwise it creates a `dsc_en` property on hardware that can never use DSC, misleading userspace.

**Concern -- nlanes always reports all three:**
```c
link_caps.nlanes = DRM_DP_1LANE | DRM_DP_2LANE | DRM_DP_4LANE;
```
Some i915 ports may support fewer lanes (e.g., TypeC in DP-alt mode may only support 2 lanes). This should use `dig_port->max_lanes` to build the bitmask accurately.

---
Generated by Claude Code Patch Reviewer