Migrate the full-stack samples to the cn1-app-kit cn1lib after it is released #6156

The app kit (maven/cn1-app-kit, #6152) ships with the next Codename One release. It is a cn1lib with a client part and a server part:

• Client: com.codename1.appkit.Net, Skeleton and Chart.
• Server: com.codename1.appkit.server.Caller, Text and Grants, plus security.AccountSecurity and the push.* family.

None of the samples use it yet. Each of the full-stack samples (wayline, savor, parley, skirmish, bastion, reel) still carries its own copy of these classes.

The kit is versioned with the framework, so it must be published before the samples can depend on it.

Steps after the release

• Confirm that cn1-app-kit-common, cn1-app-kit-backend and cn1-app-kit-lib are on repo.codenameone.com at the release version.
• In each sample:
  • Add the cn1lib dependency at ${cn1.version}.
  • Delete the sample's copies and switch its imports to com.codename1.appkit.
  • Declare Grants from a @Bean method. Nothing in the kit is a bean on its own.
  • Configure an explicit issuer for AccountSecurity. Without one, the issuer is derived from the request's Host header.
• Bastion and skirmish differ slightly from the shared copy. Keep their stricter behaviour in subclasses or in the sample.
• Update sync-initializr-template.py and check-template.sh so a generated project resolves the kit, and add the module to each sample workflow's paths.
• Prove that a downloaded template builds against published artifacts only (starter-canary.yml).
• Verify each sample with its server and client mvn verify, run-e2e.sh, run-web-e2e.sh and check-template.sh.

Follow-up extraction

These classes are nearly identical across the samples and should move into the kit with per-sample parameters:

• Session
• SignInForm
• SecurityConfig
• Moderation
• Telemetry
• AccountEndpoint

After that, the parts that are only alike in shape: Ui, Nav, Accounts, AdminEndpoint, DemoAccounts, SettingsForm and E2e.