Fix bugtracker #238: summary table ordered by its columns, not by folio

SummaryQueryWidget::queryStr() built its ORDER BY from the columns the user
chose to display, in the order they chose them:

    column   += key;
    order_by += key;

So a summary whose first column is Title came out sorted alphabetically by
title, and one starting with Author sorted by author. A table of contents
lists the folios of a project; its order is the project's order, not
whatever the first column happens to be.

It now orders by "pos", the folio position that project_summary_view already
exposes from diagram.pos. That column is an INTEGER, so the sort is numeric
and folio 10 does not land between folio 1 and folio 2. One row per folio
means pos fully determines the order, so no secondary key is needed.

Demonstrated against a stand-in view holding four folios:

    ORDER BY title, pos   Apple(2) Banana(3) Mango(10) Zebra(1)
    ORDER BY pos          Zebra(1) Apple(2) Banana(3) Mango(10)

The hand-written query path (m_edit_sql_query_cb) returns before this and is
untouched, so anyone wanting a different order still has one.

ctest 4/4, Qt 5.15.18.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

sources/dataBase/ui/summaryquerywidget.cpp

@@ -63,7 +63,6 @@ QString SummaryQueryWidget::queryStr() const
 	QStringList keys = selectedKeys();
 
 	QString select ="SELECT ";
-	QString order_by = " ORDER BY ";
 
 	QString column;
 	bool first = true;
@@ -72,14 +71,29 @@ QString SummaryQueryWidget::queryStr() const
 			first = false;
 		} else {
 			column += ", ";
-			order_by +=", ";
 		}
 		column += key;
-		order_by += key;
 	}
 
 	QString from = " FROM project_summary_view";
 
+		//Always ordered by the folio's own position, never by the columns
+		//the user happened to choose to display. This is a table of
+		//contents: it lists the folios of the project and its order is the
+		//project's order. Ordering by the displayed columns instead meant
+		//that choosing, say, Title as the first column silently sorted the
+		//summary alphabetically (bugtracker #238).
+		//
+		//project_summary_view exposes the position as "pos", from
+		//diagram.pos, which is an INTEGER -- so this sorts numerically and
+		//folio 10 does not land between folio 1 and folio 2. One row per
+		//folio means pos fully determines the order and no secondary key is
+		//needed.
+		//
+		//A user who wants a different order can still write the query by
+		//hand; that path returns above, untouched.
+	QString order_by = " ORDER BY pos";
+
 	QString q(select + column + from + order_by);
 	return q;
 }