New milestones land at the end because the sort order is a count, not a choice

The createMilestone admin action in portal/admin/actions.ts sets the sortOrder field by counting existing milestones. The line reads const count equals await prisma.milestone.count where projectId matches. A project with zero milestones gets its first at sort order zero. A project with three milestones gets its fourth at sort order three. The count query runs before the create call, so the value is always one behind the new total — which is exactly the zero-indexed position at the end of the list. No drag-and-drop API. No reorder endpoint. No manual position input in the admin form. The admin types a name, submits, and the milestone appears at the bottom. This only works because the admin interface does not support reordering or deleting milestones. They are append-only. If the interface ever added drag-to-reorder, the count trick would break because deleting or moving a milestone would leave gaps in the sequence. The constraint is a design decision — milestones represent a linear project timeline, not a shuffleable backlog. You plan them in order and you execute them in order. The count-as-position pattern mirrors that assumption in the database layer.