feat: Allow dots in organization/scope names

[philkunz]

Updates validation rules to allow dots (.) in organization names while maintaining backward compatibility with existing names.

Backend changes:

• Allow dots in ScopeName validation (api/src/ids.rs:30)
• Prevent leading/trailing dots (e.g., .org, test.)
• Prevent consecutive dots (e.g., foo..bar)
• Add new error variants for dot validation
• Add comprehensive test coverage for dot patterns

Frontend changes:

• Update regex to allow dots (frontend/utils/ids.ts:9)
• Remove underscore support to match backend validation
• Add validation for leading/trailing dots
• Add validation for consecutive dots
• Update error messages for consistency

Valid examples: my.org, foo.bar, foo.bar.baz, org.name-123
Invalid examples: .foo, foo., foo..bar

Reasoning

Allow Open Source projects to mirror their project domain as org name.

PR Checklist

• The PR title follows
  conventional commits
• Is this closing an open issue? If so, link it, else include a proper
  description of the changes and rason behind them.
• Does the PR have changes to the frontend? If so, include screenshots or a
  recording of the changes.
  
  If it affect colors, please include screenshots/recording in both
  light and dark mode.
• Does the PR have changes to the backend? If so, make sure tests are added.
  
  And if changing dababase queries, be sure you have ran sqlx prepare
  and committed the changes in the .sqlx directory.

[Ionaru]

While I don't think allowing dots in scope names is wrong in principle, it provides some challenges beyond just widening the allowed characters on the jsr website and backend.

@philkunz Maybe discuss this with the JSR maintainers during their open office meeting: https://discord.gg/V3z7A25S?event=1388890175240667197

These are the problems I can think of:

---

On Windows machines, it is problematic to install packages using a dot in their name.

And the package name will need to be wrapped in quotes like this: npx jsr add "@foo.example/bar".
This will cause the default copy-able command in jsr.io to fail.

I am not sure if wrapping the package name in quotes has effects on other operating systems

---

The jsr CLI tool will also need to be modified, as it does its own check for valid scope/package names here: https://github.com/jsr-io/jsr-npm/blob/main/src/utils.ts

(Maybe deno add and other package managers too)

[KnorpelSenf]

I don't really think this is desirable. Most orgs have a name (not just a URL) so I don't see why this is needed. Also, this isn't allowed on npm. So my 2c are that I'm against this.

[philkunz]

@KnorpelSenf Since when are dots not allowed on npm? They are!!!! All foss.global scopes have dots on npm and mirror the project domain. It is allowed on gitlab, it is allowed on npm, it is a nice mapping to the ultimate authority, the domain.

[KnorpelSenf]

@philkunz can you provide a link to npmjs.com to a scoped package with a dot in the scope name? I have actually been able to find one, this is so uncommon that I literally assumed it was not possible

[philkunz]

The emphasis being on "assumed", but stated as fact... -> The only other major platform not allowing dots is github. Gitea and GitLab don't have problem with dots. There is also no reason to not allow dots, since url paths allow dots as unreserved characters (see rfc 3986).

https://www.npmjs.com/package/@push.rocks/smartdata
https://www.npmjs.com/package/@apiclient.xyz/unifi
https://www.npmjs.com/package/@design.estate/dees-comms

[philkunz]

@KnorpelSenf So... Have I convinced you and you throw your support behind this one?

[KnorpelSenf]

Sure, if npm allows it, then it would likely ease the migration if JSR did the same. That being said, it is still strange to me why anyone would want to do this in the first place (but that's my personal take and not a reason to block anything)

[philkunz]

@KnorpelSenf Cool :) Can you review the change?

[KnorpelSenf]

I have no power here, my review does not help you get this merged