docs: fix incorrect system-contract address and token-type/enum errors in evm and native pages

## summary

four factual errors in documentation page bodies, found during the #732 accuracy audit. these are content bugs (wrong code, wrong enum, wrong token type), not frontmatter or link issues. a developer copying the affected snippets would call the wrong system contract or reference a non-existent status code.

## bugs

### 1. `ed25519-integration.mdx` calls the wrong system contract (highest impact)
`evm/differences/native-devs/ed25519-integration.mdx` routes the HIP-632 `isAuthorized` and `isAuthorizedRaw` calls to `address(0x167)` (the Hedera Token Service). these functions live on the Hedera Account Service (HAS) at `0x16a`. copying this code calls HTS instead of HAS and fails.

- expected: `address(0x16a)`
- confirmed against `evm/development/forking.mdx`, the `evm/hedera-services/hybrid` system-contract table, and the HIP-632 release note in `networks/release-notes/services.mdx`.

### 2. `native/files/errors.mdx` has a truncated status code
the error table lists `FILE_CONTENT_EMPT`. the canonical protocol enum is `FILE_CONTENT_EMPTY` (see `reference/protobuf/miscellaneous/responsecode.mdx`).

### 3. `erc721.mdx` mislabels erc-721 as fungible
`evm/tokens/erc721.mdx` note reads "`ERC-721` Token addresses refer to full Hedera Token Service (HTS) fungible token entities." erc-721 is a non-fungible standard; should read "non-fungible token (NFT) entities."

### 4. `erc721-foundry/part1-mint-burn.mdx` names the wrong standard
`evm/tutorials/advanced/erc721-foundry/part1-mint-burn.mdx` says the OpenZeppelin Contracts library "provides a standard and secure implementation of the ERC20 token." this is an erc-721 tutorial; should read "ERC-721 token."

## status

fixes are drafted on branch `docs/body-bug-fixes-732`.