ref(seer): Add priority-based root node selection to snapshot_to_markdown

[Mihir-Mavalankar]

• Sort root nodes by data.priority (descending, default 0) and render only nodes at the highest priority level. This lets frontend components declare their importance so the backend selects the most relevant context without frontend route-based filtering.
• Currently root nodes don't have priority but the followup frontend PR will add it- ref(seer): Use priority field instead of frontend route filtering #113717

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 00c9422. Configure here.}

[Zylphrex]

Just a question around why priority is stored inside data instead of being lifted to the node but otherwise LTGM

[Zylphrex]

Where is the name of this coming from? Should this be in a constant somewhere explaining why they're being skipped? Should it be stored separately from the actual data so we don't need to do special handling by comparing it against a hard coded key name?

[Mihir-Mavalankar]

Each page defines the priority of root nodes on it. So say on dashboards, the dashboard page root has priority 0 so it's but into the LLM on page context. Now if the user opens a new widget pullout on that dashboard it should get higher priority i.e. and should be put into the on page context rather than the original dashboard since that's what the user is interacting with. The logic in the function only puts the root nodes with the highest priority in the on page context.
Priority is only relevant for root nodes. The continue here is just to skip it once they are sorted and processed and to not the add the priority explicitly into the LLM on page context.

[azulus]

I like the idea of making it a const as well. You can reference the key when setting the vals on the json blob as well, ts has a nice shortcut syntax for that: {[SOME_CONST]: some_val}

[Mihir-Mavalankar]

Okay I'll move it a be an optional property node so we don't need this special handling here.