docs: ProfileMethod descriptor taxonomy + field type draft

[ryukzak]

Stacks on #158.

Design groundwork for the follow-up PR series that moves profile-method derivation out of the TS writer onto `SnapshotProfileTypeSchema`.

What this PR contains

Just docs — `docs/design/profile-methods.md`. Two sections:

1. Taxonomy

Catalogs every emit the TS writer currently produces inside a profile module, grouped into 8 categories:

• Class constants — `canonicalUrl`, slice-match records
• Static factory — `from`, `is`, `apply`, `create`, `createResource`, `resolveInput`
• Lifecycle — `constructor`, `toResource`
• Field accessors — param / auto / choice
• Slice accessors — single / unbounded / constrained-choice / type-discriminator
• Extension accessors — complex / single-value / generic
• Validator — `validate()`
• Module type aliases — `Raw`, `Flat`, `*SliceFlat`, `SliceFlatAll`, `_extFlat`

Each entry has its source helper and emit condition.

2. `methods` field type — first draft

Proposes the language-neutral `ProfileMethod` tagged union (22 variants) plus shared records:

```ts
export type ProfileMethod =
| { kind: "static-canonical-url" }
| { kind: "static-slice-match"; def: SliceMatchConstant }
| { kind: "static-from"; baseType: TypeIdentifier; hasMeta: boolean }
| { kind: "static-is"; baseType: TypeIdentifier; mode: "resource" | "extension" }
| { kind: "static-apply"; ... }
| { kind: "static-create-resource"; ... }
| { kind: "static-create"; viaResolveInput: boolean }
| { kind: "static-resolve-input"; subSlices: SubExtensionSlice[] }
| { kind: "constructor"; baseType: TypeIdentifier }
| { kind: "to-resource"; baseType: TypeIdentifier }
| { kind: "field-get"; field: FieldAccessorSpec }
| { kind: "field-set"; field: FieldAccessorSpec }
| { kind: "slice-get"; def: SliceSpec }
| { kind: "slice-set"; def: SliceSpec }
| { kind: "extension-get"; spec: ExtensionAccessorSpec }
| { kind: "extension-set"; spec: ExtensionAccessorSpec }
| { kind: "validate"; checks: ValidationCheck[] }
| { kind: "type-alias-raw"; ... }
| { kind: "type-alias-flat"; subSlices: SubExtensionSlice[] }
| { kind: "type-alias-slice-flat"; ... }
| { kind: "type-alias-slice-flat-all"; ... }
| { kind: "type-alias-extension-flat"; ... };
```

Everything is language-neutral — identifiers stay as `TypeIdentifier`, values stay as `unknown`. Renderers consume the array and dispatch on `kind`.

Open questions

Listed at the bottom of the doc:

• Single ordered array vs. bucketed-by-kind.
• Slice/extension `flavor` as a sub-field vs. a sub-variant.
• Whether validation belongs in `methods` or a separate array.
• Whether to encode helper imports or let renderers re-derive.
• Whether type aliases should split out of `methods`.

What this enables

• Multi-language reuse — Python/C# renderers consume the same descriptors with their own emitters.
• Snapshot inspectability — `bun run src/cli/index.ts typeschema generate` could dump descriptors without running a language writer.
• Testability — descriptors are pure data; today's tests assert generated text via snapshots, which is coarse.
• Stability — adding a new method kind becomes "add a variant + a renderer" instead of "edit the writer's monolithic generator".

Not in this PR

• Concrete implementation of `SnapshotProfileTypeSchema.methods`.
• Renderer migration (writer becoming a dispatcher).
• Multi-language renderers (Python/C#).

Those land in follow-up PRs once the descriptor shape is approved.