Reorder query tuple fields to prevent index drift

[Copilot]

Addresses feedback from #116: adding id at the beginning of the query tuple changed all field indices, making the code harder to maintain.

Changes:

• Moved id field to end of SELECT query: (image_tag, markdown, shell, owner_id, embed_key, id) instead of (id, image_tag, markdown, shell, owner_id, embed_key)
• Added inline comment documenting tuple field order
• Updated destructuring to match new order

// Before: id first, shifts all existing indices
let (project_id, image_tag, markdown, shell, owner_id, mut embed_key) = ...

// After: id last, preserves existing field positions
let (image_tag, markdown, shell, owner_id, mut embed_key, project_id) = ...

This preserves the original field positions when new fields are added.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Yashb404]

@copilot what is the point of this ? also will it break production ?

[Copilot]

@copilot what is the point of this ? also will it break production ?

Purpose: This change addresses a code maintainability issue without changing functionality. The previous code placed id at the beginning of the query result tuple, which shifted all the existing field positions. By placing id at the end instead, we preserve the original field positions, making the code less error-prone when modified.

Will it break production? No, this will not break production. The change is purely a reordering of how we destructure the query results - the same data is retrieved and the same variables are used in exactly the same way. The SQL query returns the same data, just in a different order, and the tuple destructuring matches that order.

What changed:

// Before: (project_id, image_tag, markdown, shell, owner_id, embed_key)
// After:  (image_tag, markdown, shell, owner_id, embed_key, project_id)

All variables (image_tag, markdown, shell, owner_id, embed_key, project_id) are still extracted and used identically throughout the function. The SQL SELECT order matches the Rust tuple type, so there's no data mismatch.