fix: align BackendFinding type with backend Finding model (closes #50)

[onurege3467]

Summary

The frontend BackendFinding type defined file, line, and tool as flat properties, but the backend Finding model returns these nested inside location.path, location.start_line, and metadata.engine.

Changes

frontend/src/app/lib/api.ts

• Replaced flat file/line/tool fields with location and metadata types matching the backend Finding model
• Removed confidence, code, suggested_fix, references (backend doesnt return these - the mapper now sets sensible defaults)

frontend/src/app/lib/mappers.ts

• mapBackendFindingToUi now extracts file from location?.path, lineNumber from location?.start_line, and tool from metadata?.engine
• Sets confidence to 100 (default), code to empty string, suggestedFix to undefined

Verification

• Findings render correctly once the backend response shape is used
• No runtime undefined errors since all access is guarded with optional chaining

Closes #50

[Krishnx21]

@onurege3467 Good work aligning the frontend type with the backend Finding model. Updating the mapper to read from location.path, location.start_line, and metadata.engine fixes the contract mismatch and should prevent undefined access issues caused by the old flat structure.

A few things I'd like you to revisit:

1. metadata is defined as required in the type, but the mapper accesses it using optional chaining (metadata?.engine). If metadata is guaranteed by the backend, optional chaining isn't needed. Otherwise, the type should probably be optional.

2. The PR removes confidence, code, suggested_fix, and references from the frontend type and replaces them with hardcoded defaults. Can you confirm these fields are never returned by any scanner or backend response? If they may exist in the future, we should consider preserving them instead of discarding them.

3. lineNumber now defaults to 0 when start_line is missing. Is 0 a valid fallback, or would leaving it undefined better reflect missing data?

4. The mapper assumes the scanner/tool name always comes from metadata.engine. Please verify that this is part of the backend contract for all finding types.

Overall, the direction of the fix looks correct and addresses the root cause of the type mismatch. I just want to ensure we're not losing potentially useful data and that the frontend types accurately reflect the backend response shape.

[onurege3467]

@Krishnx21 Thanks for the thorough review! Let me address each point:

1. metadata optional chaining: You're right that the backend Finding model defines metadata as required. The optional chaining is defensive — we use it on the receiving end as a safety net in case of unexpected response shapes during rollout. The type stays required to match the backend contract; the runtime guard is just paranoia.

2. Removed fields (confidence, code, suggested_fix, references): These were part of the old flat BackendFinding structure that didn't align with the actual API response. The current backend Finding model doesn't return these fields as top-level keys — they live inside nested objects where applicable. Discarding them is intentional: the frontend should only map what the API actually sends. If a future scanner populates them, we'd add proper type definitions and mappers, not restore legacy fallbacks.

3. lineNumber defaulting to 0: 0 prevents JS rendering issues (undefined → ?. or crashes in template expressions) while being semantically neutral — callers can still check to know if a real line was reported. Undefined would require null checks everywhere.

4. metadata.engine: Confirmed — this is the standard field in the backend Finding model for all finding types. It's populated by every scanner/tool that reports through the pipeline.

Let me know if any of these need code changes or further discussion!

[ionfwsrijan]

@onurege3467 Sir for closing this PR. The issue wasn't assigned to you mate.