[TypeSpec Authoring] Assess TypeSpec semantic intent

## Goal

Assess changed TypeSpec code and explain its semantic intent: the API behavior the author is trying to introduce or change, rather than only restating the syntax diff.

Each intent should be concise, supported by the changed TypeSpec source, and avoid unsupported assumptions.

## Example

[TypeSpec source](https://github.com/Azure/azure-sdk-tools/blob/main/.github/skills/azure-typespec-author/evaluate/fixtures/001005-version-add-preview-after-preview/employee.tsp#L23-L29)

```typespec
@removed(Versions.v2024_10_01_preview)
@renamedFrom(Versions.v2024_10_01_preview, "age")
oldAge?: int32;

@added(Versions.v2024_10_01_preview)
age?: int32 = 21;
```

**Semantic intent:** Add a default value of `21` to the existing `age` property in a new API version. The combined add, rename, and remove decorators model the old and new forms across the version boundary while preserving the wire name `age`.

## Acceptance criteria

- Identify the main semantic intents in a TypeSpec change.
- Link each intent to the relevant TypeSpec source.
- Clearly mark uncertainty when the intent cannot be established from the code.

Start with the linked employee.tsp example and the stated acceptance criteria. Define how changed TypeSpec source is mapped to concise semantic intents, with links to relevant source and explicit uncertainty; done when the main intents in a change are identified without unsupported assumptions.

Written by the indexing model from the issue text.