AppmodService naming inconsistency across sample apps (rust vs java)

## Summary
The sample apps use **inconsistent naming** for the "same" application across object types and between apps (rust vs java). Surfaced while investigating an IAM `PassRole` failure (fixed generically in #816). **Not a functional break today** (see verification), but confusing for participants and it coupled IAM to a name substring.

## Naming map (kro path, current `feature/agent-platform`)

| Concern | rust | java |
|---|---|---|
| AppmodService / Service / Rollout | `rust-microservice-` | `java-webservice` |
| `-` suffix | **yes** | **no** |
| type suffix | `-microservice` | `-webservice` |
| `image_name` | `rust-microservice` | `java-app` |
| serviceAccount | `rust-service-account-` | `java-service-account` |
| KubeVela `Application` wrapper | `rust-application` | `java-application` |
| ingress path | `/rust-app` | `/java-app` |
| DynamoDB table | `rust-app-table-` | (n/a, dynamodb disabled) |
| derived IAM role (`${name}-role`) | `rust-microservice--role` | (none) |

So a single app appears under **3-4 different base identifiers** (`*-microservice`/`*-webservice`, `*-application`, `*-app`), rust carries an `-` suffix and java does not, and `image_name` diverges from the k8s name for java.

## Verification (services are functionally consistent)
- `services.yaml` names match the AppmodService name and the Rollout `stableService`/`canaryService` refs (`${name}` / `${name}-preview`) for **both** rust and java.
- The content instructions document `cp services.yaml ...` and use the same names (`java-webservice`, `rust-microservice-`).
- ✅ No service-name mismatch code↔content. The E2E "service 'java-app' not found" came from naming the AppmodService `java-app` (a deviation from the templates), not from a code/content gap.

## Why it still matters
- **Clarity**: participants see `rust-app`, `rust-microservice`, `rust-application`, `rust-app-table` for one app.
- **IAM coupling (now mitigated)**: the `${PREFIX}-cluster-mgmt-eks` `eks-access-management` PassRole only matched `*-microservice-*`, so any app not named `*-microservice-*` (e.g. `java-webservice`, or a participant-chosen `rust-app`) that enables DynamoDB would fail PassRole. #816 decouples this via a pod-identity `iam:PassedToService` condition.

## Proposed convention (for discussion)
Pick one base name per app and use it everywhere (AppmodService, Service, Rollout, SA, image_name, KubeVela Application, ingress path, table prefix), with a **consistent** (or no) env suffix:
- Option 1: `-microservice` for all (rust stays, java `java-webservice` -> `java-microservice`).
- Option 2: drop the type suffix -> `` (`rust`, `java`), simplest.
- Standardize the `-` suffix (apply to both or neither).
- Align `image_name` with the k8s name.

## Scope of the alignment change
- `applications/{rust,java,...}/deployment/templates/{kro,kubevela}/*` (appmod-blueprints, target `feature/agent-platform`).
- Content repo `platform-engineering-on-eks` (all locales) — AppmodService manifests, service copy steps, ingress paths, Backstage/Kargo project names.
- Keep #816 regardless (removes the IAM name coupling).

Start by comparing applications/{rust,java,...}/deployment/templates/{kro,kubevela}/* with the corresponding platform-engineering-on-eks manifests and content in all locales. First agree on one naming convention and environment-suffix policy, then trace each application name through services, rollouts, service accounts, images, ingress paths, tables, and project names. Done means the selected convention is applied consistently across both repositories without relying on name substrings.

Written by the indexing model from the issue text.