Document workspace file resolution logic

## Issue Type

- Other (Documentation)

I see there is resolution logic for this, but it is not yet documented.

Ref. source:
https://github.com/BentoumiTech/denox/blob/7774ec1709bdfc5b9dc756a6b4642ac849274455/src/parser/deno_workspace.ts#L12-L27

https://github.com/BentoumiTech/denox/blob/7774ec1709bdfc5b9dc756a6b4642ac849274455/src/const.ts#L3-L14

I think it would be good to reconsider the resolution order based on some rules. [This is how ESLint does it.](https://eslint.org/docs/user-guide/configuring#configuration-file-formats) Here is a suggested idea with included reasoning:

(**Don't support extensionless `deno-workspace`** because of ambiguity — but if you feel strongly about this, explain clearly which format(s) are valid without an extension, e.g. `yaml`/`json`)

1. First, files that begin with `deno-workspace` (not dotfiles because in the event of a conflict, the dotfile is potentially hidden and could be a surprise).

2. Next, in the following extension order, preferring more human-readable formats and static files, which offer better security at the cost of flexibility (more on this below):
- `.yaml`
- `.yml`
- `.json`
- (no extension would go here **if it is not a script**)
- `.ts`
- `.js`

3. Files that begin with `.deno-workspace` following the same extension order as above

So, the suggested order would be:

- `deno-workspace.yaml`
- `deno-workspace.yml`
- `deno-workspace.json`
- `deno-workspace` (if it is **not a script**)
- `deno-workspace.ts`
- `deno-workspace.js`
- `.deno-workspace.yaml`
- `.deno-workspace.yml`
- `.deno-workspace.json`
- `.deno-workspace` (if it is **not a script**)
- `.deno-workspace.ts`
- `.deno-workspace.js`

## Security

It appears that when evaluating workspace script files, they are evaluated with the permissions inherited from `denox`, which is suggested to be `--allow-all` at installation. Is that correct? If so, that could be very dangerous.

Static configuration files are easier to reason about than dynamic scripts, so they are easier to secure.

Read src/parser/deno_workspace.ts lines 12-27 and src/const.ts lines 3-14 to document the current workspace file resolution behavior. Compare the proposed ordering with the linked ESLint guidance and clarify the security implications of evaluating workspace scripts with inherited permissions. Done means the supported filenames, resolution order, and permission behavior are clearly documented.

Written by the indexing model from the issue text.