Fix potential TypeError parsing lane_number in vegbilder.js

[Kayd-06]

Description

This PR fixes a bug in modules/services/vegbilder.js where lane_code.match(/^[0-9]+/)[0] is accessed directly without verifying if lane_code.match actually returned a match array.

When the match returns null (if the string does not start with digits), parsing it causes a TypeError: Cannot read properties of null (reading '0').

Changes:

• Used a fallback expression lane_match ? lane_match[0] : '0' to safely prevent accessing [0] on null, making the parsing logic more robust.

[matkoniecz]

How exactly this bug could have been triggered?

[Kayd-06]

It triggers if the API returns a string for FELTKODE that does not begin with a number (e.g., "unknown", "N/A", or an empty string ""), causing the regex match to return null:

// Example of failing API response property
const properties = { FELTKODE: "unknown" }; 
const { FELTKODE: lane_code } = properties;

// lane_code.match(/^[0-9]+/) evaluates to null
// Trying to access [0] throws the exception:
const lane_number = parseInt(lane_code.match(/^[0-9]+/)[0], 10); 
//  TypeError: Cannot read properties of null (reading '0')

Because loadTile processes multiple features from the API in a batch, a single unexpected FELTKODE value throws this uncaught exception, which crashes the entire feature loop and prevents the rest of the images in that tile from rendering.

This fix safely handles that edge case by falling back to lane 0 (forward direction) when the parser encounters a non-numeric FELTKODE:

const lane_match = lane_code.match(/^[0-9]+/);
const lane_number = parseInt(lane_match ? lane_match[0] : '0', 10);
//  Parses to 0

[matkoniecz]

And how one may reproduce it while using iD? Was it at least reported to happen?

[Kayd-06]

It hasn't been explicitly reported as a user-facing issue yet, I found this via code review while looking for potential runtime exceptions.

Because loadTile processes all features from the Vegvesen API in a batch, it's currently completely trusting the API contract. If the API returns even a single feature with a malformed FELTKODE (e.g. "" or "NaN"), lane_code.match() evaluates to null. Accessing [0] on null throws an uncaught exception that silently crashes the entire loadTile loop, preventing any other valid photo dots in that tile from rendering.

While this might be rare in practice, I figured adding a defensive ternary fallback here is a low-risk way to ensure the data ingestion loop remains robust and degrades gracefully to a forward directionEnum if the upstream API data is ever dirty.